I want to use automapper with a structure that uses WCF + DTO's but I want to know how the question of the eager loading with entity framework 4.0 work with the mappings of the automap.
I recently use Automapper with LightSpeed ORM (which makes Entity Framework look like a prototypea btw). It just works. It wont matter if your entities are eager or lazy loaded or used via WCF or not. Automapper is resolving the referenced entities the same way you would in your own code.
"well, I just want to know if there is any issues with eager loading and the automapper auto-mapping feature. "
No.
In fact so "No." that it makes me wonder why you would think there would be problems.
Eager loading fills properties up with data.
Automapper moves property values around.
What exactly are you trying to do?
Related
The Entity Framework uses proxy classes for some of its internal stuff, as seen in this question we have to disable it, because it cause issues with the serialization of the objects.
My question is what will be the consequences if I disable the ProxyCreation globally in my project (to avoid serialization issues) ...???
They are mainly around enabling lazy loading, but can provide some performance improvement for persisting changes, though honestly I'd say this is highly situational to present anything that is noticeable.
I would be cautious about the need to serialize entities. For instance if it is to return entities from a controller/API I would recommend defining POCO view models or DTOs that reflect the data needed by the consumer for this purpose rather than serializing the entities. The key reasons for this is that serializing entities can expose more information about your data than the consumer needs, which also means more data sent across the wire than was needed. It also can represent a misleading representation of the data in the sense that collections/references that are not eager loaded will be #null, so does that later mean that they have no data, or that it simply wasn't loaded?
Autofac supports .ProjectTo<T> which integrates into EF's IQueryable operations to simplify mapping to view models vs. using .Select.
While we mostly use fluent configuration for our code-first POCOs, we have found it useful to use data annotations for things like the table name, PKs, etc. since it makes it easier for non-EF components that don't have a reference to the ObjectContext to interact with these entities.
In our experience, it seems that the two configuration styles can be mixed freely, with fluent configuration overriding DataAnnotations. Is this documented anywhere? Is there any risk to doing this mixed configuration?
We are currently using EF 4.3.1
You can use Data Annotation attributes and Fluent API at the same time. Entity Framework gives precedence to Fluent API over Data Annotations attributes.
I personally haven't ran into any issues with mixing the code first fluent api and data annotations. I also wondered if there would be any crossover pain and I can honestly say I have yet to find any. Here's a few references to case studies on the subject to ease your mind.
(Direct from the EF team)
http://msdn.microsoft.com/en-us/data/jj591583.aspx
(Part 1)
http://www.codeproject.com/Articles/476966/FluentplusAPIplusvsplusDataplusAnnotations-plusWor
I don't think it's a risk - as both things have equivalent counterparts for the most of it.
But, personally, when I run into some sort of issues around structuring my entities - first thing I do is to remove annotations if any - and move all to fluent.
Which over time led me to use pretty much straight fluent configuration (also freeing my my objects of any ties with the Db 'state of mind')...
IMO it is 'safer' but only in a way that you can do more and control
things exactly as you'd want them. Also helps with keeping things
consistent and in one place.
I'm working on an n-Tier Domain Driven Design project that uses Entity Framework 4 DB-First and Automapper to produce POCO's in the Domain's namespace.
To clarify: The EF project returns entities in the MyProject.Repositories.EF.Entities namespace and I use Automapper to turn them into entities in the MyProject.Domain.Entities namespace.
Now, I can't quite make out if when I map between the EF and Domain entities, if all the collection properties are enumerated, i.e. if all the related data is also retrieved from the DB when they are mapped, or if they are still only lazy loaded when I actually enumerate them in code.
I am concerned about the obvious performance implications.
Turns out the answer is no. As long as you map between two IEnumerables, the actual enumeration will only take place when you perform a foreach, ToList(), etc. If you don't perform actions on IEnumerable properties of these objects, the enumeration will never happen and the related data will not be retrieved.
Long story short - this is not a concern of AutoMapper, but of how you use your ORM. AutoMapper merely removes code you would have already written, so if you would have written lousy performing code against your ORM, AutoMapper will happily oblige.
People were abusing ORMs before AutoMapper, while using AutoMapper, and after using AutoMapper. Lazy loading is a powerful tool when used correctly, but still can be abused. Using lazy loading does not preclude the developer from understanding what is actually happening underneath the covers.
So use AutoMapper, but take care with your fetching, just as you should be doing had you NOT used AutoMapper.
Does the EF5 support object state tracking out of the box for disconnected entities or do we have to write our own implementation of it.
If so, are there any good reference examples out there?
Self tracking entities (STEs) seem to be the thing you want. Ther used to be this template, but it seems Microsoft is not so fond of STEs anymore. They advise you to read this though. They explain here why.
Apart from the fact that it’s open source and mature, what are the differentiating factors that separate nhibernate from rest of the .net ORM frameworks like Subsonic, ADO.NET Entity Framework etc?
Better put, why should I choose nhibernate over other .net entity frameworks?
The biggest reason is probably that nHibernate supports persistence ignorance; your entities can be plain old CLR objects (no base class). It also supports unit of work (updates are automatically tracked and batched) which Subsonic does not support. Also, Entity framework does not support implicit lazy loading (when you want to access Order.OrerItems, you have call Order.OrerItems.Load()). It forces you to think about lazy loading, but also pollutes your buisness logic with infrastructure concerns.