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
Related
I'm new to EF4 and I'd like to know what the best approach when using EF with stored procedures as part of the DAL. So far I have these two options:
Option 1
Using EF4, I can create a complex type that the EF will map my results from stored procedures. I can then return this complex type from the DAL layer and then convert it again into custom BLL object in the main application layer. This strategy is appealing to me since I would rely on EF4 designer to build the plumbing without me building parameters by hand. It also makes DAL stand alone without referencing the assembly that contains the business objects. The major issue that I see with this approach is the fact I have to sort of hydrate DAL complex type to BLL business object again. Not sure how it would affect the performance.
Option 2
Have DAL reference assembly that contains BLL object and then return BLL objects from DAL layer. I'm not really sure if this is the right approach for me. I would have to manually create stored procedure parameters and then iterate of DataReader to build business objects to return. It's doable, but I would rather let EF4 designer build me stored procedure plumbing. Also, it would seem to couple DAL with BLL assembly, which I'm not sure is appropriate.
Would appreciate some comments on this and suggestions.
Thanks!
There is a third option - make your business objects entities. EF is tool to persist and retrieve business objects from the database but you make it just data access layer with need to manually convert its results to business objects. That is whole source of your problems.
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
In a previous question, #Darin Dimitrov answered:
In your case the worst thing is that
you are using your Linq2Sql models
inside your views and that's one of
the worst anti-patterns I see people
doing in ASP.NET MVC applications. You
absolutely should be using view
models. That's what views should be
passed from controllers and that's
what controllers should get from
views.
Why is it so bad to pass Linq2Sql objects as Models?
There are a lot of reasons why it's bad to pass Linq2Sql objects as models to your views and controllers, and it would be relatively difficult to cover all of them in a single answer. So, here are my top 3:
Separation of Concerns - Linq2Sql objects have DAL logic embedded in them, which is a violation of SoC. Also, you will likely want to validate data passed from your views, which should be done in the Model (NOT the controller!). However, if you add this logic to your L2S models then you also violate SoC (not to mention the fact that your validations will be wiped out if you regenerate your L2S models)
Encapsulation - Your L2S classes have a lot of members that your view(s) and controller(s) likely do not need access to. A proper model would encapsulate these members to keep them inaccessible.
Maintainability and Reusability - At some point you may decide you want to change your backing store. If you use your L2S classes as models then you'll end up touching a LOT of code to make that change, whereas if you roll your own models then you'll only have to worry about changing your models and nothing else. Also, not messing with your L2S models (see SoC above) means that they're reusable across projects.
In addition to Brian Driscoll's excellent answer, I would add that with LINQ to SQL or the Entity Framework, you don't always know what values actually exist on the objects you've been given. Let's say your view model included a User object from Linq2Sql. You may be tempted to do something like this:
Messages (<%: Model.User.Messages.Count() %>)
Because the Messages property exists on the user object, it's easy to assume that this is totally fine. However, the results of this action aren't entirely clear.
If you have lazy loading enabled, but the context has been disposed, an exception will be thrown.
If you have lazy loading disabled, you'll probably end up with "Messages (0)"
If you have lazy loading enabled, and the context is active, this will cause every single message associated with that user to get loaded into memory, just to figure out how many there are.
On the other hand, if you used LINQ to generate a ViewModel that contains the information you know you'll need to generate your view, it might look like this:
using (var context = _contextFactory.Get()) {
return (from u in context.Users
where u.UserId == userId
select new UserSummary {Name = u.Name, MessageCount = u.Messages.Count())
.Single();
}
This uses a single SQL query to get all the information you'll need for this view, while ignoring any information you won't need (like the entire contents of the user's inbox). If some future developer wants to add information to this view, they're going to have to ensure it's populated on the ViewModel as part of the data-access logic.
Not only Linq-To-Sql objects, but any entity object should not be exposed to the view.
It reveals your data schema to the end user( a hacker might find it usefull)
It violates the separation of concerns principle in mvc.
When your entity objects lazy load inside the view, it is not much different to have used the data access logic inside the view. So the whole point of layering your application is gone.
We do like EntityFramework (CTP5) quite a lot and Using it along with ASP.NET MVC3.
What I dislike is;
things are mixed in together.
I can place a DisplayAttribute, RequiredAttribute, RangeAttribute, CompareAttribute together in the same class which means I am mixin in database validation, some business logic and UI alltogether. I can even place ScriptIgnore attribute to customize it as a Json DTO object. So I can use the same POCO class for Persistance, Presentation, DTO and Business Object, and as my domian model.
Which design patterns do you follow along with EF POCO + MVC3 toolset. What layers do you have?
What resposibilities do you add to your classes (Is Your POCO class also your Domain Model)
I use View Models to solve this problem. Validation and UI presentation attributes go to the view model. In this pattern the controller uses a repository to fetch an EF model, maps this EF model to a view model (I use AutoMapper for this) and passes the view model to the view. Because the view model contains all the UI presentation attributes the view behaves as expected. Each view must have its own view model. This means that you could have multiple view models associated to the same EF model but contain a different subset of properties and display formatting attributes based on the specific requirements of the view.
The process works the other way around as well: the controller receives a view model from the view as argument. It maps the view model back to a model and passes the EF model to the repository. UI validation attributes are handled on the view model because you could have different validation requirements in different views: think for example Insert/Update views. In the insert view you will be creating a new entity thus the Id property won't be required. You won't even have an Id property on your view model in this case. In the update view on the contrary the Id property will be required.
My POCO classes are almost always domain models and almost never view models so I don't have these problems.
The best practice is to use special "view model" class when passing data from controller to view (or as JsonResult). In such case you mark UI based attributes in that view model. In most cases (except pure crud applications) you need to display something more or something less then your domain object so you still need some view model (unless you use ViewData directly).
Data annotations on domain object makes sense only if you want to use them for business/data level validation which can take different rules then UI validation.
If you want to follow strict DDD where POCO classes are domain objects = offers methods performing domain logic on instance of object you should go even further because in such case your business facede should not expose domain objects to controller. In such case you will end up with data transfer objects exposed on business facade and consumed in controller. I'm not purist so in this scenario I'm open minded to using data annotations on DTOs directly but it depends on another requirements.
I'm using NHibernate to persist my domain objects.
To keep things simple I'm using an ASP.NET MVC project as both my presentation layer, and my service layer.
I want to return my domain objects in XML from my controller classes. After reading some posts here on Stack Overflow I gather DTOs are the way to go. However, I've also come across posts talking about the ViewModel.
My question: Are Data Transfer Objects and ViewModels the same thing? Or is a ViewModel a kind of sub pattern of a DTO?
The canonical definition of a DTO is the data shape of an object without any behavior.
ViewModels are the model of the view. ViewModels typically are full or partial data from one or more objects (or DTOs) plus any additional members specific to the view's behavior (methods that can be executed by the view, properties to indicate how toggle view elements etc...). You can look at the viewmodel as all the data for a view plus behaviors. ViewModels may or may not map one to one to business objects or DTOs.
By the way, NHibernate projections come in handy if a certain viewmodel needs a subset of the data from a persisted object.
ViewModel in ASP.NET MVC practice is the same as the DTO, however ViewModel in MVVM pattern is different from DTO because ViewModel in MVVM has behaviors but DTO does not have.
DTO != ViewModel
In the MVVM pattern the ViewModel is used to isolate the Model from the View. To represent the Model you could use simple DTO classes, which again is mapped to a database through e.g. NHibernate. But I've never seen a ViewModel class which is modelled as a DTO.. ViewModel classes mostly have behavior, which DTOs don't have.
DTO - Data Transfer Objects are exactly as it says, containers for transferring data. They have no behaviour but merely a bunch of setters and getters. Some people make them immutable and just create new ones when needed rather than updating existing ones. They should be serializable to allow transfer across the wire.
Generally DTOs are used to ship data from one layer to another layer across process boundries as calls to a remote service can be expensive so all the required data is pushed into a DTO and transferred to the client in one chunk (coarse grained).
However, some people use the notion of screen bound DTOs (nothing to do with crossing process boundries). Again these are populated with the required data (generally the data required for a particular screen and could be an aggregation of data from various sources) and sent to the client.
http://blog.jpboodhoo.com/CommentView,guid,21fe23e7-e42c-48d8-8871-86e65bcc9a50.aspx
In simple cases as has already been stated this DTO can be used for binding to the view but in more complex cases it would require the creation of a ViewModel and unloading of data from DTO to ViewModel which is obviously more work (when applying MVVM pattern).
So again as already stated DTO!=ViewModel
and
DTO and ViewModel have different purposes in life
For some simple views I'll use my DTO as my models, but as Views become more complex I'll create ViewModels.
For me it is a balance between quickness (using DTO, since I already have 'em) and flexibility (creating ViewModels means more separation of concerns).
First, the major difference is that ViewModel can have behaviour or methods that DTO Must Not !!!
Second, Using DTO as a ViewModel in ASP.NET MVC make your application tightly coupled to DTO and that's exactly the opposite purpose of using DTO. If you do so, what's the difference using your domain Model or DTO, more complexity to get an anti-pattern ?
Also ViewModel in ASP.NET can use DataAnnotations for validation.
The same DTO can have different ViewModels Mapping, and One ViewModel can be composed from differents DTO (always with object mapping not composition) . because i think it is even worse if you have a ViewModel that contains a DTO, we will have the same problem.
From your presentation layer, think about DTO as a contract, you will receive an object that you have to consider as stranger to your application and don't have any control on it (even if you have ex the service, the dto and presentation layers are yours).
Finally if you do this clean separation, developpers can work together with ease.
The person who design ViewModels, Views and Controllers don't have to worry about the service layer or the DTO implementation because he will make the mapping when the others developpers finish their implementation...
He can even use Mocking tool or manual mocking to fill the presentation layer with data for test.
If you need to change or enhance the DTO then create a ViewModel. It's also OK for the ViewModel to reference the DTO as a complex property.
In practice, you will generally want to add view-specific properties or methods to the model you are using in the view. In such cases,
never modify the DTO for your view requirements. Instead, create a ViewModel and map from your DTO to the ViewModel.
If you will use DTO as ViewModel, that means you are making high dependency on DTO because of some reason you are changing DTO then it could impact on ViewModel.
Better use DTO & convert into viewmodel.
We can use DTO same as Model class and we can use viewmodel when we needs to show/use multiple models data/property in a single view. Example: I create some model using entity framework database first. So, now all the model generate based on the database. and now we need data annotation, for those data annotation we can create a folder name DTO, In this DTO folder, we can keep all the models exact which already generate and add data annotation above the property. Then we can use any operation(use controller , views) using this DTO classes. And when we need complex view, I mean when we need multiple classes data in one view there we can use viewmodel. For viewmodel we can create a folder name viewmodel, then create a custom class and keep that property which we need. I tried to clear myself. Any suggestion highly appreciated.