I have POCO's in a separate project and now I need Self Tracking Entities. Does anyone know if I need to generate new POCO's that are self tracking and they will replace my current POCO's? Or, do I setup self tracking entities in addition to my current POCO's?
Thanks!
You do not need both. STE is essentially POCO with additional capability for change tracking when disconnected from the ObjectContext. I would suggest that you stick with STE if you have n-tier scenario. For non N-Tier scenario meaning when you are working with your entities on the server side, you can use it like a poco object and let ObjectContext manage change tracking for you.
Related
My Question is about returning EF entity using WCF service. As wcf required Data Members for returning data. Solution i have to do mapping of entity to WCF data members which is quit hectic.
Is there possible solution which reduce my work effort. I tried EntityFramework with WCF - how to return EF entities but available solution have support for vs2010
only.
This is tricky question. You want to pass EF entities through WCF. This is bad in some way, because EF objects are burdened with additional data provided by EF (e.g. for change tracking purposes). The best way to pass objects through domains in your application is create DTO objects. To do that, you can develop additional mappings (with usage of T4 templates) that create this DTOs based on your existing EF entities.
I have following layers in my applicaiton
Date Layer (reference to Model)
Business Layer(reference to Model ,Data)
Model
Service(WCF)-(reference to Model,Business Layer)
UI (WPF/Silver Light) - Connected via WCF service
How do i detect the changed poco entities in an ObservableCollection in UI layer?
for sending it back to server from client side for saving ? instead of sending all data back to sever side(via WCF)?
or
how to perform add/delete/update operation on entities in the collection in UI layer?
I am using
VS2010/2012
C#
EF 5
ADO.NET POCOEntityGenerator With WCF Support(for generating .tt templates from Model.edmx)
SQL Server 2012
Even though searched a lot of places I didn't find a proper solution..
please help if any ideas...
Thanks...
The method i followed to create My application is given below link
http://www.toplinestrategies.com/dotneters/net/wcf-entity-framework-and-n-tier-solutions-part-2/?lang=en/comment-page-1/#comment-1954
Only proper solution is to do the change tracking manually. Each POCO object will have IsDirty property and each property of this object will have IsDirty = true in it's setter.
One way to make it less manual would be to create a framework, that will create wrapper classes, that will do this for you, but this requires large dose of reflection and code-generation. Also, it will still require all properties to be defined as virtual.
But generally, you want to refrain from making UI that would require this kind of tracking. When you want to change an entity, load only that entity in Edit window.
POCOs are well-suited for transmitting data between client and server. However, if you’re looking for objects to actually work with on client and/or server side you may want to consider using self-tracking entities (STE) as these entities contain logic to track their actual changes and status.
Yet a better solution is to use the N-Tier Entity Framework which provides functionality to work with EF in n-tier applications. See http://ntieref.codeplex.com/ for more details.
If you are using EF, then your entities have a 'HasChanges' flag you can test against before submitting changes to your context.
e.g.
if (this.CurrentEntity.HasChanges || CurrentEntity.EntityState == EntityState.New)
{
this.SubjectContext.SubmitChanges(Submit_Completed, saveDetails);
}
All,
We are using EF as our primary data access technology. Like many apps out there, we have a business objects/domain layer. This layers talks to our repository, which, in turn, talks to EF.
My question is: What is the best mechanism for passing the data back and forth to/from EF? Should we use the EF-generated entity classes (we did DB-first development, so we have entity classes that EF generated), create our own DTOs, use JSON or something else?
Of course, I could make an argument for each of these, as well as a counter-argument against them. I'm looking for opinions based on experience building a non-trivial application using a layered architecture and EF.
Thanks,
John
I would use POCOs and use them with EF. You can still do that with the DB first approach.
The main benefit is that your business objects will not be tied to any data access technology.
Your underlying storage mechanism can, and will, change but your POCOs remain. All that business logic is easily re-used and tested.
As you're looking for cons, then I would say it might take longer. However, that cost is well worth it.
With t4 templates I put the actual EF generated entities in a common project that is referenced by all other projects. I use the EF database first created models through the entire application (including use as view models). If I need to add additional properties to an entity that are not in the database I just extend the partial class of the entity in the common project. I have written dozens and large nTier applications using this model and its worked great.
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
Hello
I wonder what's the difference between standard EF objects, POCO and Self Tracking Entities. I was looking the web but couldn't find a valuable introduction.
Any help would be appreciated.
POCO is plain class with only mapped fields. STE is very similar but in advance it contains logic implemented to each property and some collections which are used to tracking changes made to entity.