C# – LINQ to SQL – Business logic in another assembly

asp.netclinq

So I am trying my hand at this whole tiered application thing with ASP.NET 4. The software I've developed is a maintenance nightmare and it isn't very well organized. I've done some looking around the web and can't seem to find an example of what I'm looking for here. Someone please pick this design apart.

My Data Access Layer will be an assembly with LINQ to SQL.

I will have a Business Logic Layer that references the DAL assembly and does what BLLs do. Very general and basic stuff.

Then I will have a business objects class that does some that is data-related but is more "work" type stuff – like generating documents, etc.

The web site will interact with the BLL and the business objects.

So: 

    DAL
     |
     |
     |
    BLL----------BO
     |           |
     |           |
     |           |
    Web----------|

Am I making this way too complicated?

Should I just put my business logic right in there with the LINQ classes in the DAL? I'm not sure how a DataContext would work in a separate assembly with classes that inherit from LINQ classes. Thoughts?

Best Answer

That works fine. Referencing and consuming your DataContext from the DAL is no different than dealing with any other kind of class.

I tend to create my own classes that mirror LINQ classes (usually as WCF entities) instead of trying to extend LINQ entities directly. There is a lot of overhead in keeping LINQ objects around too long, it might be a non-issue for you in a web based environment if you're only keeping objects around for one request/response.

I have also seen DataContext's defined in their own assembly, then application-specific functionality grafted on to LINQ entities by way of a partial class and/or extension methods. That works ok, so long as the DataContext/Entities don't change in an unexpected, critical way.

Related Topic