I've used Entity Framework 4.0 POCO entities for persistence layer in the current project.
I've used DTO's to send the data from Service Layer to UI Layer. Repositories and inside of Service Layer have used POCO.
There is a Mapping Layer to map (DTO to Domain(POCO) and (Domain(POCO) to DTO). At the moment, we manually track the changes.
For example, If entity id is zero we assume that entity is a new one and if not entity is an update.
Is there any way to achieve this other than implementing IsTransient(New), IsDirty(Update) or IsDeleted(Delete) properties manually in Entity Framework 4.0?
If you use your custom DTO you must always implement your own change tracking.
EF 4 offers only self tracking entities but that would require you to use these entities directly instead of DTOs and they have some other disadvantages.
Related
By default Spring Data Repositories process database Entities. Please, suggest the standard approach of getting same functionality with Spring Data framework, which allows you operating on your Business Domain Objects (DTO) instead of Entities, and encapsulates all DTO to/from Entity mappings.
My current obvious options are:
Additional "proxy-wrapper" where all methods have same names as in Spring Repository but accept and return DTO types and encapsulate conversions(mappings).
Some clever implementation of previous option using AOP with less boilerplate code.
Both options seem pretty awkward to me for such a standard task. So, I assume I am jut missing something here.
I haven MVC app, with "M" including Service and Repository layers.
However, I am a little confused as to where and how to do a couple of things.
One Service calling two repositories, or calling it's own repository and another service
e.g.
I have a ReferenceDataService, which handles all of the logic for CRUD with my reference tables.
Then in my "CustomerService" I need to 'R' my reference data to get e.g. Description instead of Id. So, do I call the ReferenceDataService or ReferenceDataRepository?
At some layer I'd like to map from Entity to ViewModel.
Do I do this in my Service layer, or in the Controller?
e.g. Does my ServiceLayer do the mapping/logic from VM to Entity and back?
Thanks:)
Repositories talk to an underlying data source.
Service layer talks to repositories with domain models. It takes/passes domain models from/to the repository layer.
Controller talks to service layer. Controller takes/passes domain models from/to the service layer.
Controller calls mapping layer (if any) to map between the domain models and view models. If you don't have a mapping layer you could do the mapping in your controller although this could quickly become cumbersome in which case AutoMapper could serve as a very handy mapping layer.
Another more simpler scenario is when you don't need a service layer which is often the case in smaller applications. A service layer brings no benefit. So the controller talks directly to the repositories with the domain models.
ViewModel contains data, required for displaying model on view. If you'll use another view (e.g. mobile application, or desktop application, or even web service) you will require another data to be displayed on view. If you'll do mappings on service layer, then you will not be able to use it with another type of application. Thus controller is a place where you map domain data to display them on view (whatever type of view you have).
I am creating a UML diagram using COMET UML profile for my MVC application.
I distinguish between Information Model which describes the application entities, such as the domain model, and the Component Model, which describes the high level components of the application and the relationships between them.
In my case the Component Model describes database, Entity Framework, Repository, Service, Controller and Views. I grouped Entity Framework and Repository under Data Access Layer(DAL), the Services under Service Layer(SL) and the Views under User Interface(UI).
I have to find a place where to put the Controller (not a service nor a UI) and how to model the Database. I do not think it is a component but in UML there is no database object. Any tip on how to model them?
I will start to code a new Web application soon. The application will be built using ASP.Net MVC 3 and Entity Framework 4.1 (Database First approach). Instead of using the default EntityObject classes, I will create POCO classes using the ADO.NET POCO Entity Generator.
When I create POCOs using this tool, it automatically adds the Virtual keyword to all properties for change tracking and navigation properties for lazy loading.
I have however read and seen from demonstrations, that Julie Lerman (EF Guru!) seems to turn off lazy loading and also modifies her POCO template so that the Virtual keyword is removed from her POCO classes. Julie states the reason why she does this is because she is writing applications for WCF services and using the Virtual keyword with this causes a Serialization issue. She says, as an object is getting serialized, the serializer is touching the navigation properties which then triggers lazy loading, and before you know it you are pulling the whole database across the wire.
I think Julie was perhaps exagarating when she said this could pull the whole database across the wire, however, even so, this thought scares me!
My question is (finally), should I also remove the Virtual keyword from my POCO classes for my MVC application and use DectectChanges for my change tracking and Eager Loading to request navigation properties.
Your help with this would be greatly appreciated.
Thanks as ever.
Serialization can indeed trigger lazy loading because the getter of the navigation property doesn't have a way to detect if the caller is the serializer or user code.
This is not the only issue: whether you have virtual navigation properties or all properties as virtual EF will create a proxy type at runtime for your entities, therefore entity instances the serializer will have to deal with at runtime will typically be of a type different from the one you defined.
Julie's recommendations are the simplest and most reasonable way to deal with the issues, but if you still want to work with the capabilities of proxies most of the time and only sometimes serialize them with WCF, there are other workarounds available:
You can use a DataContractResolver to map the proxy types to be serialized as the original types
You can also turn off lazy loading only when you are about to serialize a graph
More details are contained in this blog post: http://blogs.msdn.com/b/adonet/archive/2010/01/05/poco-proxies-part-2-serializing-poco-proxies.aspx
Besides this, my recommendation would be that you use the DbContext template and not the POCO template. DbContext is the new API we released as part of EF 4.1 with the goal of providing greater productivity. It has several advantages like the fact that it will automatically perform DetectChanges so that you won't need in general to care about calling the method yourself. Also the POCO entities we generate for DbContext are simpler than the ones that we generate with the POCO templates. You should be able to find lots of MVC exampels using DbContext.
Well it depends on your need, if you are going to serialize your POCO classes than yes you should remove them (For example: when using WCF services or basically anything that will serialize your entire object). But if you are just building a web app that needs to access your classes than I would leave them in your classes as you control the objects that you will access in your classes through your code.
I'm trying to architect my MVC web project and I'm running into a bit of a problem.
I am using EF4.1. I've created a DataAccess project with the EDMX file. Then I use the dbContext generator to make my POCO .tt classes.
As it is right now, my Business logic layer can access the POCO classes just fine, but the presentation layer cannot.
I think that I'm supposed to create another level of abstraction and put the dbContext .tt files into their own project so that both the BusinessLogic layer and the Presentation layer can access the POCO classes, but only the BusinessLogic has access to the entity framework. The presentation layer shouldn't need to know anything about EF.
Something like this...
POCO Classes - DataAccess
| |
|---------Business Logic
| |
|_________Presentation
Am I on the right track here, and if so, do I simply cut/paste the .tt files into the new project or is there a way to force the dbContext add-on to create these in my other project?
Your presentation layer doesn't have to know anything about the EF. Just reference that project from your presentation layer to access the models.
However - your presentation layer shouldn't ideally be using any of those POCO models. They should be using ViewModels. I dont necessarily believe in the DTOs here as DTOs have a specific purpose. Your repository/data access can return models but generally those get returned to a service layer. The service layer then would return your ViewModel representation to your controller.
This sets you up nicely for dependency injection as well, since into your controller you just inject your service layer. Into your service you can inject then any repositories you need, and so on.
Ironically I think I may be working on a book for this exact subject shortly : )
Consider sending Data Transfer Objects between your Business Logic and Presentation layers. This would allow you to shape the data for your views and and prevent information from leaking into the Presentation layer (e.g. if you have a field in your POCO that is needed for your business logic but doesn't need to be available in your Presentation layer).
The question is, how would you move data to and from the
presentation layer? Put another way, should the presentation layer
hold a reference to the domain model assembly? (In an Entity Framework
scenario, the domain model assembly is just the DLL created out of the
EDMX file.)
From a pure design perspective, DTOs are a solution really close to
perfection. DTOs help to further decouple presentation from the
service layer and the domain model. When DTOs are used, the
presentation layer and the service layer share data contracts rather
than classes.
A layer of DTOs isolates the domain model from the presentation,
resulting in both loose coupling and optimized data transfer.
If you go this route, also check out Automapper to help with mapping your DTOs to POCOs and vice-versa.
So there are several ways to structure your project. What you are referring to is one way, in which you share poco's between all layers.
Another way is to have your POCO's be in the data and business layer, then create a similar object model that's shared between UI and business layer. Finally, you might also create a third model for the UI only called teh ViewModel.
It all really depends on your needs. If your object model is very complex, then you might need to simplify it with ViewModels.