Asp.Net MVC and Entity Framework Architecture

views:

answers:

+2 Q:

Asp.Net MVC and Entity Framework Architecture

Hi,

I'm working on a fairly large project at the moment and am currently in the planning stages. I've done a lot of reading into the various patterns suggested for development, somthing that has split the team at the moment is when using Entity Framework should the classes be passed through the applciation layers so that a view accepts an Entity Framework class or should these classes be mapped to BLL Classes and if so at which point (Controller or Library) should this be done?

I'm interested in hearing some positives and negitives for each solutions.

+2 A:

This is again one of those questions that doesn't really have a right or wrong answer, its personal taste really. Personally I would opt for using DTO's or interfaces when passing data to the Views. I don't tend to pass around entity objects to different layers of my application they are strictly confined to the DAL, or if I do need to pass it up a layer I would almost always use an interface never the concrete type.

James 2010-05-17 10:26:16

Thanks James! I know its hard to andwer, but Im after the pros and cons, so why do you not pass entity objects around?

Pino 2010-05-17 10:31:05

Properties are lazily loaded by default hence if you are passing around an entity (which has properties as such) you will always have to ensure you have a DC available to you. Also if it is purely data you are passing, then a DTO just *fits* better.

James 2010-05-17 10:35:10

How about namings and structure? Do yuo find the DTO are named much the same as the entity objects? Anyone know of any example project structures?

Pino 2010-05-17 12:02:15

@Pino, yes if I had an entity object called `Customer` I would usually name my DTO something like `CustomerDto` so I know which entity the DTO refers to.

James 2010-05-17 12:17:25

@James Lets say Customer can have Order History which links to the order history table (Via a many to many table) do you include the link in your DTO or if you wanted to get a set of order history create and load the object as needed? The Entity framework allows you to do Customer.OrderHistory.All() etc

Pino 2010-05-17 12:33:04

@Pino: That is something that you would have to decide based on your application. Your customer dto could have a property called `OrderHistory` which is a list of `OrderDto` and when creating your customer dto you could populate this information aswell. My advice would be retrieve what information you require (I tend to include other table information in my DTO if necessary)

James 2010-05-17 12:40:36

Thanks James!!!

Pino 2010-05-17 12:49:15

@James Final question, where do you do the conversion from Entity object to DTO? Do you use a constructor in the DTO itself?

Pino 2010-05-17 13:03:21

You could use a contructor to take in the parameters to make it easier to contruct, however, if you are asking *where* I would instantiate them.....what I tend to do is extend my entity type to have a method called `AsDto` which creates the DTO interally and passes it out e.g. `MyEntityDto = MyEntity.AsDto();`

James 2010-05-17 13:10:25

@James, Nice idea I assuem this uses some kind of automatic binding? Can you point me in the direction of some more reading on this?

Pino 2010-05-17 13:22:37

@James or offer some examples/links.

Pino 2010-05-17 13:34:24

@Pino: Not that I am aware of. You could possibly achieve that using Reflection.

James 2010-05-17 13:41:30

@james, So you are not using the Entity Framework?

Pino 2010-05-17 13:53:41

@Pino: See http://automapper.codeplex.com/

James 2010-05-17 13:57:42

Seen it and used it, but interested to know about the method you mentioned. I can only assume you dont use Entity Framework? @james

Pino 2010-05-17 13:59:10

@Pino: I use a whole range of tools....entity framework being one. I don't use an automatic mapper I created a method (like I mentioned earlier) which maps the properties to DTO internally, as already mentioned you could look at Reflection for an automatic solution.

James 2010-05-17 14:11:41

Automatic isnt really what I was looking for, I'm going to have a look into trying what you have suggested. So do you extend the entity class for every table?

Pino 2010-05-17 14:16:21

@Pino: Only the tables that will require DTO's, not all my tables did. Its quite a nice design (I felt) as internally if you come across the problem you were mentioning earlier (what if you have a different table which is a 1..n relationship) when creating your DTO you can map them by doing something like `customerDto.OrderHistory = MyEntity.OrderHistory.Select(o => o.AsDto()).ToList();`. It works well for me.

James 2010-05-17 14:25:26

+3 A:

This is one of those great "it depends" questions ....

For me it's a matter of pragmatism. I use the raw entity classes where ever I can for expediency. I start using DTOs when either the object graph in question starts becoming too cumbersome or the object in question has sensitive data I don't want sent over the wire.

Doobi 2010-05-17 10:31:53

ansaurus

tags:

views:

answers:

Asp.Net MVC and Entity Framework Architecture

related questions