In the official documentation, it's mentioned that DTOs can be used as breeze entities:
It does not have to be an ORM class. It could be a DTO class that you will later map into a class in your business model via your implementation of BeforeSaveEntities.
In a comment by Ward Bell, he suggests the following strategy for saving DTOs alongside EF Entities:
Remove DTO from EntityInfos
Retrieve corresponding business model entity from Db (or create such an entity if this is an insert)
Update this copy from DTO
Add this entity to the EntityInfos (don't forget the OriginalValues properties for an update)
Rinse and repeat for all such DTOs
Let it go ... and EF will save it
Intercept the "after save" and remap the updated/inserted business entity into its DTO form in the SaveResult so that you send the DTO, not the "real" entity, back to the client.
The problem with this recommendation is with step 4. The EntityInfo.Entity property is defined as internal. How can you create an EntityInfo with the proper EF Entity?
One alternative to this recommendation would be to override the SaveChangeCore method and handle the mapping of DTOs to EF Entities in that method. The downside to this is that the EFContextProvider.SaveChangesCore has a lot of code and I'd rather not duplicate that effort.
I found ContextProvider.CreateEntityInfo(). It has an overload that accepts an entity and sets the EntityInfo.Entity property.
Related
I'm confused about "the journey" of the data and I need some confirmation. Could you check this underneath and correct me if necessary. It's also not clear to me in case of an insert.
On one hand, I have a "simple DAL" with POCO Objects, a Mapper converting IDataRecord into POCO Objects and Services in charge of Connexion and Command to communicate with the DB.
On the other hand, I have an MVC project with Model Objects, Controllers in charge of asking the DAL Services to work for them, and a Mapper which converts Model Objects to POCO Objects and also the POCO Objects into Model Objects.
And finally, the views...
In case of retrieving the Data from the DB, I understand the journey of those data like this :
the View sends an httprequest to the Controller
the Controller uses the DAL Services to connect to the DB and execute a query
the DB sends back some IDataRecord
the DAL Mapper converts those IDataRecord into POCO Objects
the MVC Mapper converts those POCO Objects into Model Objects
the Controller sends those Model Objects back to the View
the View displays them on the page
In case of inserting the Data to the DB, I understand the journey like this :
the View send Model Objects to the Controller
the MVC Mapper converts those Model Objects into POCO Objects
the Controller asks the DAL Services to connect to the DB and insert the data thanks to a query
the DB gets the data and stores them
In case of an insert, the DAL Services can send straightaway the POCO Objects to the DB whereas in case of retrieving the Data from the DB, we first need a mapper to convert the IDataRecord into POCO Objects.
Is that right?
Thanks in advance
That is - as far as I can tell - correct in a DB first approach. However in a code first approach there is no POCO object and the developer writes those classes.
First of all I want to ask that what is the difference between Entity Class and our Model Class ?
And when I use to add Data Annotations on the Entity Classes generated by the Entity Framework in Database approach, it's vanished upon every "Update From Database", and for this user defined Model Classes can be used but I have no idea to use them with the generated Entity Classes.
An entity class is a class that directly associate's with a real object and is linked to business logic and holding information about the system. Entities are usually used to establish a mapping between an object and to a table in the database.
Models are simply classes that are associated with a views and controllers which define or contains the definition of an object and when there has been a change in state. These can hold your data annotations to validate before going up to the Business/Data Access layers...
This leads me on to your next question and if using EF to generate your data model classes using the "database first" approach, then you cannot apply the data annotation attributes directly to your classes. Because the EF Designer generates the model classes, any changes you make to the model classes will get overwritten as you have been experiencing. If you want to use the validators with the classes generated by EF then you need to create meta data classes: http://blogs.microsoft.co.il/blogs/gilf/archive/2011/01/20/adding-metadata-to-entities-in-the-data-model.aspx
Hope that helps.
Danny
Ok straight to the issue. I can get object mapping to tables easily with Linq To Sql. For instance: class Product, class Order, class Order_Detail from Northwind. IMO, these 3 object have already met model's meet. But i can't put some useful attr([Required] [HttpPost]) on properties of them(except modifying design.cs, which is not recommended).Do i have to create ProductModels OrderModels with the same properties myself, and maybe some additional DAL-like classes to turn the linq2sql objects to models??
EDIT:
Even if i put design.cs and my models in the same namespace, how can i make two partial classes have the same properties??
Yes, you should create DTO's for each Linq to SQL model, it is not considered a good practice to pass Linq2Sql objects through your layers.
Optionally, look into to using Entity Framework Code First. It is stupid simple to use and you can add validation attributes directly to your POCOs, which are enforced on the data persistence side as well as the presentation side in MVC.
here's a good EF codefirst primer : http://weblogs.asp.net/scottgu/archive/2010/07/16/code-first-development-with-entity-framework-4.aspx
I really have two questions:
What is the difference between an Entity Framework Entity object and an ADO.NET C# POCO Entity.
Do I have updating a record using a repository correct below?
If you turn off code generation, then add the ADO.NET C# POCO Entity Generator, it provides a nice class representation of your Entity Framework 4 objects. The idea is that (from here):
The POCO Template can be used to generate persistence ignorant entity types
from an Entity Data Model.
However, these objects have the relations between objects as well as a link back to the database. For example, you can pull one out of your repository, alter it, then save changes at the repository or unit of work level, and it saves the content to the database.
So my question is what is different between a native Entity Framework object and these POCOs generated using this tool?
This is what I think when I update a record using a repository. Is this wrong?
Request a POCO from the repository.
The Repository loads the records from the data context, creates a new POCO for each record found, copies the values from the Entity Framework objects to the POCOs, and returns a collection of the new POCOs.
Changes are made to these POCOs outside of the repository, then the POCOs are submitted back to the repository using something like Save(POCO).
The repository loads the matching records from the database and copies the POCO properties to the Entity Framework objects.
One calls Save using either the repository object or unit of work object.
In case of POCO generator the generated entity classes (eg, Employee, Company etc.) don't derive from any special class (hence called Plain Old).
Whereas in case of entityobject generator, the entity classes derive from the special 'EntityObject' class, which provides certain capabilities.
The objective behind having POCO classes is to do away with the DB specific concerns of an entity. Thus keeping our domain model unaware of DB/persistence operations.
POCO means that you have a plain old CLR class which is not polluted by special constructs related to the persistance. Entity objects are derived from EntityObject class and they use a lot of classes and attributes directly related to entity framework. When using EntityObjects you are making your code fully dependent on entity framework.
What you describe in your repository was used in EFv1 to achieve POCO approach. Currently you can use POCOs directly. POCOs don't have any relation to the database. In some scenarios POCOs are dynamically proxied by EF dependent constructs but this happens during runtime so it doesn't pollute your code.
I want to encapsulate all EF entities in business objects.
The EF entity "Investment" will have a "BoInvestment" business object that holds the entity internal and routes all properties.
For navigation properties that is a challenge.
Let's say my "Investment" has "Reports" has an EntityCollection which is lazy loaded.
My business object "BoInvestment" would need this "Reports" as "BoReports" since "Report" is also encapsulated in a business object.
If I would just return an "IList" it would mean that all Reports are always loaded into memory. I would loose the EF advantage that EntityCollection is only a Querable until it is materialized.
Any Ideas :)
The idea is using entities directly as business objects instead of wrapping the into a new object layer. It will work much better if you use POCOs instead of Entity objects. If you want to stick with your current architecture check Lazy<T> - msdn. That could be a way to implement your navigation properties on business objects.
Why not use an IQueryable? this way you would still have the advantage of query composition and lazy loading.
Another idea would be to take advantage of the fact that the entity objects generated by EF are in fact partial classes that you can extend to include your BO functionality