Clearly separation of concerns is really a desirable trait within our code and also the first apparent step many people take would be to separate data access from presentation. During my situation, LINQ To SQL has been used within data access objects for that data access.

My real question is, where should using the entity object stop? To clarify, I possibly could pass the entity objects as much as the domain layer however i feel as if an entity object is not only an information object - it's like passing a little from the DAL up to another layer too.

Let us say I've got a UserDAL class, should it expose an entity User resist the domain whenever a method GetByID() is known as, or should it goes an ordinary data object purely for storing the information and absolutely nothing more? (appears like inefficient duplication within this situation)

Whoever else men completed in this same situation? Can there be an alternate approach to this?

Hope that wasn't too vague.



I return IQueryable of POCOs from my DAL (which uses LINQ2SQL), so no Linq entity object ever leaves the DAL. These POCOs are came back towards the service and UI layers, and are generally accustomed to pass data into the DAL for processing. Linq handles this perfectly:

 IQueryable<MyObjects.Product> items = from p in linqDataContext.Items

                                          choose new MyObjects.Product //POCO


 return items

For many projects, we use LINQ to SQL organizations as our business objects.

The LINQ to SQL designer enables you to definitely control the ease of access from the classes and qualities it creates, to help you restrict use of something that allows the customer to violate the company rules and supply appropriate public options (that respect the company rules) in partial classes.

You will find articles on applying your company logic by doing this around the MSDN.

This protects you against writing a lot of tiresome boilerplate code and you will even build your organizations serialisable if you wish to send them back from the web service.

Whether you produce a separate layer for that business logic really is dependent on how big assembling your shed (with bigger projects typically getting greater variation between your business logic and data access layers).

In my opinion LINQ to Organizations attempts use a one-stop means to fix this conundrum by maintaining two separate models (a conceptual schema for the business logic along with a storage schema for the data access).

Personally, i can't stand my organizations to spread accross the layers. My DAL return POCO's (obviously, it frequently means work, however i found that much cleaner - maybe that this is simpler within the next .Internet version -)).

Now you ask , not too easy and you will find many different considering the topic (I continue asking myself exactly the same question that you're).

You may could have a look in the MVC Store sample application : I love the essence from the concept (the mapping that happens within the data layer especially).

Hope this can help.

There's an identical publish here, however, I call at your real question is much more about list of positive actions, instead of how you want to do it.

In small programs I've found another POCO implementation to become inefficient, in bigger programs (particularly individuals that implement web services) the POCO object (often a Data Object) is helpful.

In case your application grouped into the later situation, you might want to take a look at ADO.Internet Data Services.

Hope that can help!