What does one loose by creating POCO using T4 templates in entity framework 4.0? Why is the default behavior when using entity framework 4.0 not to create POCO?
You lose a number of things. A "pure" POCO is of limited use in an ORM, because it will not do change tracking. In other words, when you mutate the object and then save changes to the context, you would like the changed properties saved to the database. With a "pure" POCO you can do this with snapshot based change tracking, which is fairly inefficient. You can also do it with runtime proxies, which force you to make your track properties public virtual, so you arguably don't have a "POCO" anymore. Also, using proxies means that you don't know the true runtime type of the instance.
You also lose some of the convenience properties like EntityState.
"Pure" POCOs cannot do lazy loading. Again, you can work around this with proxy types, but, again, if you're using proxies, you don't really have a "pure" POCO.
On top of all of this, there is less need to use POCO entities in the Entity Framework than in some other ORMs. This is because you can always project your entity types onto POCO instances using LINQ, without having to materialize the entity instances first. So "pure" POCOs are always available in an Entity Framework application, even if you don't happen to map your entities that way.
Related
Is it possible in Entity Framework using Code First to create a domain model of pure POCOs that are totally ignorant of the Entity Framework?, i.e. don't decorate any classes or properties with any attributes and annotations related to the EF, and don't use virtual keyword to be able to support lazy loading.
Can I achieve this? or do I have to make two models one for persistence model and one for domain model to achieve this.
I want to hand-write my POCO's as simple classes with virtual properties so that the entity framework can generate proxies. I will enable proxy creation (which is on by default) so I can have change tracking and lazy loading.
My question is: can I have them?
More specifically, I noticed that the POCO template generator generates classes with a FixupCollection<T>. Is that necessary to have? If I make the navigational properties in my simple hand-written POCO a virtual IEnumerable<T>, will that suffice without any FixupCollection<T> stuff?
As an alternative, I could use the POCO template generator but I do not wish to, because my model is quite large and complicated. I will need to keep making changes to the model and will need to keep editing the model class definitions. If I use the POCO template generator, every time I need to regenerate the model for some reason, it will overwrite all my custom changes.
So, is it possible to just have POCO's in the real spirit of their name?
Yes, of corse it is possible.
http://msdn.microsoft.com/en-us/library/vstudio/dd456853%28v=vs.100%29.aspx
FixupCollection class can be used by the POCO classes to keep the opposite ends of a relationships in sync.
http://blogs.msdn.com/b/adonet/archive/2010/01/25/walkthrough-poco-template-for-the-entity-framework.aspx
We are in a process of designing an application with approx 100 tables and complicated business logic. Windows Forms will be used on the client side and WCF services with MSSQL on the server.
Custom DTOs are used for client-server communication, business entities are not distributed.
Which variant of Entity Framework to use (and why):
EF 4.0 EntityObjects
EF 4.0 POCO
EF 4.1 DbContext
Something else
Database-first approach is a requirement.
Also, is it worth implementing a Repository pattern? It seems a bit redundant, as there is one level of abstraction in the mapping itself and another one in the use of DTOs. I'm currently leaned towards using auto-generated extendable repositories for each entity returning IQueryable, just to have a place to put common queries, but still allowing querying entity model directly from the Service Layer.
Which variant to use? Basically once you have custom DTO the only question is do you want to have control over entities code (their base class) and make them independent on EF? Do you want to use code first? If the answers to all questions are no then you can use EntityObjects. If you want to have entities persistence ignorant or use custom base class you should go to POCO. If you want to use code first or new DbContext API you will need EF 4.1. Some related topics:
EF 4.1 Code-first vs Model/Database-first
EF POCO code only VS EF POCO with Entity Data Model (this was related to CTP)
ADO.NET DbContext Generator vs. ADO.NET POCO Entity Generator
EF Model First or Code First Approach?
There are more things to consider when designing service layer. You should be aware of complications you will have to deal with when using EF in WCF. Your service will provide data to WinForms application and it will work with them in "detached mode". Once user will do all changes he wants to do he will post data back to the service. But here comes the problem - you must tell EF what has changed. If you for example allow user to change order with all its order items (change quantity in items, add new items, delete some items) you must say EF exactly what has changed, what was added and what was deleted. That is easy when you work with single entity but once you allow user to change object graph (especially many-to-many relations) then it is quite tough. The most common solution is loading the whole graph and merge the state from incoming DTOs to loaded and attached graph. Other solution is using Self tracking entities instead of EntityObjects/POCOs + DTOs.
When discussing repositories I would refer you to this answer which refers many other answers discussing repositories, their possible redundancy and possible mistakes when using them just to make your code testable. Generally each layer should be added only if there is real need for the layer - due to better separation of concerns.
The main advantage of POCOs is that those classes can be your DTOs, so if you've already got custom DTOs that you're using, POCO seems a bit redundant. However, there are some other advantages which may or may not have value to you, since you didn't mention unit testing as a requirement. If you plan to write unit tests, then POCO is still the way to go. You probably won't notice much difference between 4.0 POCO and 4.1 since you won't be using the code-first feature (disclaimer: I've only used 4.0 POCO, so I'm not intimately familiar with any minor differences between the two, but they seem to be more or less the same--basically I was already using POCO in 4.0 and haven't seen anything that's made me want to update everything to use 4.1).
Also, depending on whether you plan to unit-test this layer, there's still value in implementing the repository/unit of work patterns when using Entity Framework. It serves to abstract away the data access logic (the context), not the entities themselves, and allows you to do things like mocking your context in unit tests. What I do is copy the T4 template for my context and use it to create the interface, then edit the T4 template for the context and have it implement that interface and use IObjectSet<T> instead of ObjectSet<T>. So instead of:
public class MyEntitiesContext
{
public ObjectSet<MyClass> MyEntities
...
}
I end up with:
public interface IMyEntitiesContext
{
public IObjectSet<MyClass> MyEntities;
}
and
public class MyEntitiesContext : IMyEntitiesContext
{
public IObjectSet<MyClass> MyEntities
...
}
So I guess it really comes down to whether or not you plan to write unit tests for this layer. If you won't be doing anything that would require mocking out your context for testing, then the easiest thing to use would probably be 4.0 EntityObjects, since you aren't planning to pass your entities between layers and it would require the least effort to implement. If you plan to use mocking, then you'll probably want to use POCO and implement repository/unit of work.
I have not hardly touched EF4, but I've used Linq to sql quite a lot. I would like to start into one of the EF templates but I have no idea what situations make sense for each or what their intent was.
I have the following possibilities:
Data templates
ADO.NET Entity Data Model
Service-based Database (is this even related to EF?
Code templates (I am familiar with T4)
ADO.NET EntityObject Generator
ADO.NET Self-Tracking Entity Generator
Online Templates
ADO.NET C# POCO Entity Generator
I have no idea what situations make
sense for each or what their intent
was
Not meaning to sound rude, but did you have a look on MSDN/ASP.NET to find out? There is plenty of information around. And there is a lot to each of those templates, more than i can go into here. There is a MSDN page for each of these.
That being said, i'll give you a quick summary, so people who stumble here have some info.
ADO.NET Entity Data Model
This is the file you create to use Entity Framework as your ORM, and it is mandatory for using EF. You need this before you use any of the others. You can create your EDM with a number of different approaches, including database-first (generate from DB), code-first, model-first, etc.
Service-based Database
I have never heard of this term, and given i've been working with EF a lot lately (and reading), i doubt this will be related to EF.
ADO.NET EntityObject Generator
Generates classes for entities which inherit from the EntityObject class. Identical to the default EF code generator, except instead of putting output code into the Model.edmx.designer.cs (default) file, the code gets put into seperate files. I personally don't see any benefit in this template.
ADO.NET Self-Tracking Entity Generator
Generates classes for entities when you want to develop N-Tier applications (ie if you wanted to allow a WCF/Silverlight app to work with your model). Entities are setup to be 'trackable' by the EF Graph, in order to handle persistence operations from various applications.
ADO.NET C# POCO Entity Generator
My favourite. :) Generates classes for entities which inherit from nothing. They have no idea that they are being used for persistence. Use this for applications when you want persistence-ignorance, testability and loose-coupling of your domain/persistence layers.
Aside from faster development time (Visual Studio 2010 beta 2 has no T4 templates for building POCO entity objects that I'm aware of), are there any advantages to using the traditional EntityObject entities that Entity Framework creates, by default? If Microsoft delivers a T4 template for building POCO objects, I'm trying to figure out why anybody would want to use the traditional method.
You're asking two questions at the same time, it seems. Code-only versus model-first and EntityObject parent type versus arbitrary parent type. You get designer support with model-first, regardless of parent type. Aside from designer support, you can also use precompiled views with model-first. That can significantly help performance.
Having EntityObject as a parent can be an advantage over so-called "POCOs" (which are usually proxy bases, not "plain" objects), because the runtime type of your entities are the exact type you expect, rather than a runtime-generated subtype.
Also, unlike other ORMs which have minimal to no LINQ support, the Entity Framework has rich LINQ support, allowing you to project onto real POCO types. Therefore, it is possible to build truly persistence-ignorant presentations without having to care about what the base type of your entities are. You are not stuck with whatever type comes out of the ORM blackbox.
EntityObject allows for private properties which are persisted to the database. Using proxy types requires that those properties are at least protected and must be virtual. Therefore, EntityObject may allow for better encapsulation.
I'm not trying to suggest, by the way, that there aren't advantages to using proxies; I'm just trying to answer your question about what the advantages of EntityObject are.
I think the only benefit is designer support. Can't find any other benefits in using non-poco entities.