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.

I am having a bit of trouble explaining precisely the question I have here so bear with me. it is similar to the unanswered question found here: http://stackoverflow.com/questions/5580651/what-is-the-correct-way-to-use-unit-of-work-repositories-within-the-business-laye

Apologies if this is too rambling.

Scenario: + .Net solution + IRepository used to retrieve objects from DB + IUnitOfWork used to allow transactions across multiple repositories

This makes sense to me and I have implemented something along these lines that works fine. Now I want to introduce a business logic layer and am having trouble organising the three elements (BLL, UnitOfWork and Repository) in my mind.

My understanding: - Repository - data retrieval, manipulation - UnitOfWork - persistence - BLL - logic relevant to the business ('real world') (dislike that term!)

Consider we have an ASP.Net MVC front end.

I guess the question is: what does a BLL look like and what does the MVC controller that uses it look like?

For reference: I wonder if perhaps my IUnitOfWork/IRepository implementation might be the underlying cause of my confusion.

public class IRepository<T> 
{
    private IObjectSet<T> objSet;
    public IRepository<T>(IUnitOfWork uow)
    {
        objSet = uow.CreateObjectSet<T>();
    }

    public IQueryable<T> Add(T entity)
    {
        objSet.Add(entity);
    }
    //etc. etc. for delete, attach, getall
}

So I feel like if I have a BLL, I should be passing it the IUnitOfWork, so that it can use that to create the IRepository instances that it needs. But how will the BLL (separate DLL from the front end) 'know' what implementation of IRepository to build?

share|improve this question
2  
I actually thought your question was just fine. The problem is, this is a fuzzy area; there's no One True Way™ to do it, and nobody wants to give you suggestions because they don't want to be told they're Doing It Wrong™. I personally prefer a thinner, more database table-centric approach on smaller projects; all of this ceremony is really intended for large-scale, enterprise applications. –  Robert Harvey Sep 28 '11 at 16:34
    
Fair points both and the fault is then with my wording. I was interested in personal opinions i.e. 'this is how I personally would approach it'. –  glosrob Sep 28 '11 at 18:55
add comment

1 Answer

up vote 5 down vote accepted

Please note that I only have minor experience with the .NET framework and that this answer only relates to the architecture part of your question.

As far as I understood it, you are basically applying the following architectural patterns in your application:

Layers: It seems you have a persistence layer (Repository Pattern), a business logic layer and a view layer.

Model-View-Controller: This pattern is applied in the view layer using ASP.NET MVC.

I guess the question is: what does a BLL look like and what does the MVC controller that uses it look like?

First of all, this architecture is intended for large-scale, enterprise applications as Robert Harvey mentioned in his comment to your question. What is characteristic for such systems is that the domain logic (which you encapsulated in the business logic layer) should be accessible through various interfaces.

Consider Twitter for instance - Twitter could have a business logic layer which provides services for registering and validating users, posting tweets and much more. On top of this business logic layer, multiple other components could exist in the view layer, e.g. a web interface and web service component. Since all business logic is encapsulated in the business logic layer, you can follow the DRY principle and improve maintainability and other quality attributes.

To come back to your question - you should encapsulate business logic and data access in the BLL. The controller (think MVC) should make use of the BLL and should not have direct access to the database. Consider the view layer as an interface to your application.

So I feel like if I have a BLL, I should be passing it the IUnitOfWork, so that it can use that to create the IRepository instances that it needs. But how will the BLL (separate DLL from the front end) 'know' what implementation of IRepository to build?

The BLL should know which repository (data source?) it uses. The layers above shouldn't control this. Again, consider the view layer only as an interface to your business logic.

If you don't need the overhead of a business logic layer, you may also choose to use it solely for data access in form of data access objects.

I hope this helped clarifying the various components' responsibilities.

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.