I am utilizing Entity Framework 4.0 and WCF. I am new to using Entity Framework and am more familiar with NHibernate. However, I am concerned about detached instances of objects when performing an update.
I have looked on various websites where they retrieve an object, attach the instance to their context, and set all properties to be modified but this leaves two problems:
All fields are updated in the database (not a huge problem, but adds overhead for each update statement).
Many of the examples do not handle situations where you may have an IEnumerable property with objects that also need to be updated (this will be a requirement).
Is there a 'best practice' example of how to handle updating detached entity instances? Any guidance is greatly appreciated.
Brandon, are you able to make use of the self-tracking entities template? This is designed to make handling updates of detached entities much easier. http://msdn.microsoft.com/en-us/library/ee789839.aspx
Related
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.
We are using .net C# 4.0, VS 2010, EF 4.1 and legacy code in this project we are working on.
I'm working on a win form project where I have made a decision to start using entity framework 4.1 for accessing an ms sql db. The code base is quite old and we have an existing data layer that uses data adapters. These data adapters are used all over the place (in web apps and win form apps) My plan is to replace the old db access code with EF over time and get rid for the tight coupling between UI layers and data layer.
So my idea is to more or less combine EF with the legacy data access layer and slowly replace the legacy data layer with a more modern take on things using EF. So for now we need to use both EF and the legacy db access code.
What I have done so far is to add a project containing the edmx file and context. The edmx is generated using database first approach. I have also added another project that contains the POCO classes (by using ADO.NET POCO Entity Generator). I have more or less followed Julia Lerman's approach in her book "Programming Entity Framework" on how to split the model and the generated POCO classes. The database model has been set for years and it's not an option the change the table and the relationships, triggers, stored procedures, etc, so I'm basically stuck with the db model as it is.
I have read about the repository pattern and unit of work and I kind of like the patterns, but I struggle to implement them when I have both EF and the legacy db access code to deal with. Specially when I don't have the time to replace all of the legacy db access code with a pure EF implementation. In an perfect world I would start all over again with a fresh take one the data model, but that is not an option here.
Is the repository and unit of work patterns the way to go here? In order to use the POCO classes in my business layer, I sometimes need to use both EF and the legacy db code to populate my POCO classes. In another words, I can sometimes use EF to retrieve a part of the data I need and the use the old db access layer to retrieve the rest of the data and then map the data to my POCO classes. When I want to update some data I need to pick data from the POCO classes and use the legacy data access code to store the data in the database. So I need to map the data retrieved from the legacy data access layer to my POCO classes when I want to display the data in the UI and vice versa when I want to save data to the data base.
To complicate things we store some data in tables that we don't know the name of before runtime (Please don't ask me why:-) ). So in the old db access layer, we had to create sql statements on the fly where we inserted the table and column names based on information from other tables.
I also find that the relationships between the POCO classes are somewhat too data base centric. In another words, I feel that I need to have a more simplified domain model to work with. Perhaps I should create a domain model that fits the bill and then use the POCO classes as "DAO's" to populate the domain model classes?
How would you implement this using the Repository pattern and Unit of Work pattern? (if that is the way to go)
Alarm bells are ringing for me! We tried to do something similar a while ago (only with nHibernate not EF4). We had several problems running ADO.NET along side an ORM - database concurrency being a big one.
The database model has been set for
years and it's not an option the
change the table and the
relationships, triggers, stored
procedures, etc, so I'm basically
stuck with the db model as it is.
Yep. Same thing! The problem was that our stored procs contained a lot of business logic and weren't simple CRUD procs so keeping the ORM updated with the various updates performed by a stored procedure was not easy at all - Single Responsibility Principle - not a good one to break!
My plan is to replace the old db
access code with EF over time and get
rid for the tight coupling
between UI layers and data layer.
Maybe you could decouple without the need for an ORM - how about putting a service/facade layer infront of your UI layer to coordinate all interactions with the underlying domain and hide it from the UI.
If your database is 'king' and your app is highly data driven I think you will always be fighting an uphill battle implementing the patterns you mention.
Embrace ado.net for this project - use EF4 and DDD patterns on your next green field proj :)
EDMX + POCO class generator results in EFv4 code, not EFv4.1 code but you don't have to bother with these details. EFv4.1 offers just different API which does exactly the same (and it is only wrapper around EFv4 API).
Depending on the way how you use datasets you can reach some very hard problems. Datasets are representation of the change set pattern. They know what changes were done to data and they are able to store just these changes. EF entities know this only if they are attached to the context which loaded them from the database. Once you work with detached entities you must make a big effort to tell EF what has changed - especially when modifying relations (detached entities are common scenario in web applications and web services). For those purposes EF offers another template called Self-tracking entities but they have another problems and limitations (for example missing lazy loading, you cannot apply changes when entity with the same key is attached to the context, etc.).
EF also doesn't support several features used in datasets - for example unique keys and batch updates. It's fun that newer MS APIs usually solve some pains of previous APIs but in the same time provide much less features then previous APIs which introduces new pains.
Another problem can be with performance - EF is slower then direct data access with datasets and have higher memory consumption (and yes there are some memory leaks reported).
You can forget about using EF for accessing tables which you don't know at design time. EF doesn't allow any dynamic behavior. Table names and the type of database server are fixed in mapping. Another problems can be with the way how you use triggers - ORM tools don't like triggers and EF has limited features when working with database computed values (possibility to fill value in the database or in the application is disjunctive).
The way of filling POCOs from EF + Datasets sounds like this will not be possible when using only EF. EF has some allowed mapping patterns but possibilities to map several tables to single POCO class are extremely limited and constrained (if you want to have these tables editable). If you mean just loading one entity from EF and another entity from data adapter and just make reference between them you should be OK - in this scenario repository sounds like reasonable pattern because the purpose of the repository is exactly this: load or persist data. Unit of work can be also usable because you will most probably want to reuse single database connection between EF and data adapters to avoid distributed transaction during saving changes. UoW will be the place responsible for handling this connection.
EF mapping is related to database design - you can introduce some object oriented modifications but still EF is closely dependent on the database. If you want to use some advanced domain model you will probably need separate domain classes filled from EF and datasets. Again it will be responsibility of repository to hide these details.
From how much we have implemented, I have learned following things.
POCO and Self Tracking objects are difficult to deal with, as if you do not have easy understanding of what goes inside, there will be number of unexpected behavior which may have worked well in your previous project.
Changing pattern is not easy, so far we have been managing simple CRUD without unit of work and identity map pattern. Now lot of legacy code that we wrote in past does not consider these new patterns and the logic will not work correctly.
In our previous code, we were simply using transactions and single insert/update/delete statement that was directly sent to database assuming transactions on server side will take care of all operations.
In such conditions, we were directly dealing with IDs all the time, newly generated IDs were immediately available after single insert statement, however this is not case with EF.
In EF, we are not dealing with IDs, we are dealing with navigation properties, which is a huge change from earlier ADO.NET programming methods.
From our experience we found that only replacing EF with earlier data access code will result in chaos. But EF + RIA Services offer you a completely new solution where you will probably get everything you need and your UI will very easily bind to it. So if you are thinking about complete rewriting using UI + RIA Services + EF, then it is worth, because lot of dependency in query management reduces automatically. You will be focusing only on business logic, but this is a big decision and the amount of man hours required in complete rewriting or just replacing EF is almost same.
So we went UI + RIA Services + EF way, and we started replacing one one module. Mostly EF will easily co-exist with your existing infrastructure so there is no harm.
Background:
I started to create logical database model for ASP.NET MVC web site. I used visual designer for Entity framework that ships with VS because I have used it before.
But now I already have 33 classes and I'm not finished (including quite some inheritance and a lot of associations). I'm afraid that it would be too complicated and time consuming for me to manually set all the table mappings and than generate database tables. I've no experience with it - I've done it the other way: classes from database tables and it took me a lot of time to get it work in a smaller project.
Question:
How can I easily and quickly create database tables for logical model (class diagram) in .NET / VS ? It would be great if it was possible automatically. I have never worked with LinqToSQL visual designer and it seems to be no reference on the web on how to create database tables from LinqToSQL classes. Is it possible at all ? If not is there any way to create database tables with Entity framework automatically - without having to specify table mappings ?
And one side question: if I used LinqToSQL classes are that going to commit changes to database every time I change properties ? Or is some caching taking place there ?
Entity framework has a concept called "Model First", which generates the database model from you model, hence the name.
You can read about that here: http://msdn.microsoft.com/en-us/data/ff830362
However, my personal favourite when it comes to Object Relational Mappers is NHibernate with the addition Fluent NHibernate. They have a concept where you work with your domain model rather than you data model and you use conventions to control your mappings. It's pretty neat. You can get started with some pretty good examples by looking at this code here: https://github.com/sharparchitecture/Northwind/tree/master/app
Linq2Sql is too limited for the case you are talking about. And it has no capability to generate data models from code. In fact, Linq2Sql works the other way around - it generates a set of classes from your data model, much like Entity Framework also can do.
Neither Linq 2 SQL or Entity Framework commit anything until you explicitly choose to do so. They both have a notion of a object context which keeps track of all changes made. When you call "Save", they transform those changes into SQL which is then executed in the database.
Like MikeEast, I've had a very good experience with Fluent NHibernate.
On my project, I use the Automapping feature, which allows me to change my data model almost at will, and the database schema automagically gets updated.
No SQL, no worrying about foreign keys, etc, etc, etc - I love it!
Fluent NHibernate Automapping
Finally I have sticked with Entity framework - tables generating is really plainless once I learnt how to deal with database connections...
I've been reading about self-tracking entities in .net and how they can be generated from a *.edmx file. The thing that I'm struggling to understand is what generating these entities gives you over the basic EF entities? Also, some people have mentioned self tracking entities and Silverlight, but why would you use these rather than the client side or shared classes generated by RIA services?
What is the point of self-tracking entities and why would you use them?
Self tracking entities (STE) are implementation of change set (previous .NET implementation of change set is DataSet). The difference between STE and other entity types (POCO, EntityObject) is that common entity types can track changes only when connected to living ObjectContext. Once common entity is detached it loose any change tracking ability. This is exactly what STE solves. STE is able to track changes even if you detach it from ObjectContext.
The common usage of STE is in disconnected scenarios like .NET to .NET communication over web services. First request to web service will create and return STE (entity is detached when serialized and ObjectContext lives only to serve single call). Client will make changes in STE and pass it back in another web service call. Service will be able to process changes because it will have STE internal change tracking available.
Handling this scenario without change tracking is possible but it is much more complex especially when you work with whole object graph instead of single entity - you must manually merge changes received from client to current state in database.
Be aware that STEs are not for interoperable solutions because their functionality is based on sharing STE code between server and client.
The main purpose is to aid in N-tier development. Since they're self-tracking, you can serialize them over, say, a WCF service, then de-serialize them back, and they will still know which changes have been made, and are pending for the database.
Self-tracking entities know how to do
their own change tracking regardless
of which tier those changes are made
on. As an architecture, self-tracking
entities falls between DTOs and
DataSets and includes some of the
benefits of each.
http://blogs.msdn.com/b/efdesign/archive/2009/03/24/self-tracking-entities-in-the-entity-framework.aspx
I have a WCF application in C# .NET 4.0. I made all my entity classes and can query a sample from the WCF. The sample is just hard coded values.
Now I am ready to persist these in the database. I am lost on how to approach this though. I plan to create tables for each entity class I created, but what is the best way to add the persistent data layer to my existing WCF application. Is Entity Framework a good choice for this? Thanks for any help or suggestions.
What I suggest is to use entity framework code first. It prevents you from re-creating the model/database by hand. Just set it up so that your current entity classes are mapped to the entity framework and it will automatically create the database for you.
If you google entity framework code first, i'm sure u cant miss it.