Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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?

share|improve this question

migrated from stackoverflow.com Oct 8 '11 at 16:24

This question came from our site for professional and enthusiast programmers.

add comment

3 Answers

The The Onion Architecture article inspired me a great deal regarding layered architectures.

According to it, you would define service and repository interfaces in your BLL project. Implementations of these are kept in a separate service implementation project (call it the DAL if you like). Your web project references both and injects the implementations into the BLL. The BLL does not reference any of the others and only containing the service layer code, business entities and service and repository interfaces.

You could say the web project is configuring the BLL (model) with appropriate service implementations.

share|improve this answer
add comment

This DAL and BLL gives me some definite headaches :-) . From my point of view, I would suggest you to learn ASP.NET MVC, it's way better organized and easy to maintain framework. You can have a different assembly for your domain objects and interface in another. The best thing about this is you don't need to manage too many things to achieve a loose coupled application. Just give it a go and i am definite, you will like it.

share|improve this answer
add comment

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.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.