3

I have the following setup for a simple application:

  1. generated LINQ to SQL classes from my database tables (DAL?)

  2. created classes (BLL?) that use the LINQ to SQL datacontext, to insert, update, delete, select

  3. in my presentation layer, when inserting e.g. a new "product", I'm creating a new instance of object "Product", which comes from my DAL layer (this is what LINQ to SQL created for me)

My question is if this is the right way to go for separation of layers in this case. What's strange to me is that I'm using an object type that was defined in the DAL, which shouldn't be used in the presentation layer if you ask me. But if I want to make use of the LINQ to SQL objects without again creating new objects, this seemed like the way to go.

What's your advice on this? I'm not sure what's the best way to go about here.

Zoe
  • 27,060
  • 21
  • 118
  • 148
Jorre
  • 17,273
  • 32
  • 100
  • 145

1 Answers1

4

I don't think there is ever a one-size-fits-all solution, but, if you have a simple application, you probably don't want to complicate things unnecessarily If you are able to stomach keeping the data context open at your presentation tier, there are some 'productivity' gains in keeping the L2SQL entities:

  • Support for lazy loading (although watch out for the 1:N problem)
  • You have a single set of generated entities (albeit datacontext aware)

However, for a heavier, more purist architecture, you could consider

  • Wrapping the Linq2SQL artifacts in a Repository Pattern
  • Map out the L2SQL entities into POCOs before returning them to your BLL / Service Tier
  • Depending on your network and presentation architectures, you may also need to consider what you entity looks like over the network (Serialization, WCF, JSON etc) and you might also look at View Models, in which case your entity will 'change' class and shape several times as it is mapped and transformed between layers.
  • In fact, you might consider another ORM than Linq2SQL entirely, e.g. NH or EF

EDIT: You've got a couple of options if you don't want to work with the VS generated L2SQL entities in your BLL or Presentation Layer.

  • Create a new set of POCOs and then map the L2SQL entities out in your repository / dal. Automapper can simplify this task.

  • You can use your own POCOs directly in Linq2SQL, by providing an XmlMappingSource, although this is a bit more work.

Community
  • 1
  • 1
StuartLC
  • 104,537
  • 17
  • 209
  • 285
  • Thanks for your help. I'm rather happy with how easy Linq 2 SQL is so I'd like to keep that, but my only concern is that I'm using DAL entities in my presentation layer. What is the easiest way to solve that in my current setup? – Jorre Oct 10 '11 at 10:15