2

At the moment my website has a repository pattern with the specification pattern in it. I can get data from within my .aspx page with just a few lines of code, example:

private IRepository repository;

    protected void Page_Load(object sender, EventArgs e)
    {
        repository = new GenericRepository();

        Specification<Book> specification = new Specification<Book>(b => b.Year == 1988);
        lvBooks.DataSource = repository.GetAll<Book>(specification);
        lvBooks.DataBind();
    }

Now my question is, do I need a business layer in my website and if your answer is yes, why? At the moment it seems, because of the specification pattern, that I have no need for a business layer who's between the page and the repository.

Thanks for your opinion.

Julian
  • 1,105
  • 2
  • 26
  • 57

2 Answers2

3

The answer is dependant on how big this application is, how big it's going to get, and how much it's likely to change.

The only real point of any layers is to isolate functionality. In a small application you can happily have calls to the repository sprinkled throughout the UI code.

But what if you then change something in the way the repository is structured? You'll need to find and change all those references.

However if you wrote all your repository access code in a business layer which exposes higher level methods to the UI then you've got much less work to do at this point.

There could be specific security considerations. For example if your UI doesn't have access to the repository then you can focus all your security checking on the public API of the business layer. If you have a 200 page web app where the repository can be accessed from anywhere - of course it could be secure - but how certain can you be?

Then there's unit testing...... basically there is no right way - but if your app is small you're fine... if your app is large you're probably going to regret this design at some point.

James Gaunt
  • 14,631
  • 2
  • 39
  • 57
  • It'll be a big site eventually, so you should say make an BLL? How should I make the business layer look then with this specification repository? (My repository is generic and the database got like over 30 tables, so then I should write an businessobject for every entity? – Julian Aug 12 '11 at 11:45
  • Very difficult question! I would start by forgetting the UI and the repository exist. Just think about the business domain and write an API that seems to naturally fit that domain. If your repository is well designed it should be able to support this API easily - if not you probably want to change the repository. Then write the UI to make use of this API. At this point you may need to add some additional methods to the API to support specific UI requirements but try to avoid that if you can.... there have been countless books written on this subject... that's the best I can do in 6 lines. – James Gaunt Aug 12 '11 at 11:49
  • Haha, thanks. I'll think of a way to make this work although seems alot if work building a good BLL on my generic repository (because a generic BLL can't have methods for a specific entity right?) – Julian Aug 12 '11 at 11:51
  • On the question of business object -> entity mapping. In large apps I wouldn't worry about this. The more you can think of the business domain as being separate from the repository and the UI the better. It's more work upfront but more flexibility in the future. Or you can just use a 1-1 mapping, less work up front, less flexible in the future. There is no rocket science here - and no magic bullet - you just decide what to trade off against what. – James Gaunt Aug 12 '11 at 11:52
  • I don't know what you mean be 'generic BLL'... I would never use the phrase generic for a business layer... it should be the exact opposite - finely tuned to your specific domain. The way the repository is designed should be irrelevant to the design of the BLL API (this is the whole point - separation of layers)... obviously it's relevant to the internal implementation of BLL methods - but that's just plumbing. – James Gaunt Aug 12 '11 at 11:54
1

From your code it seems that you dont need business layer. As it seems its all about data fetching using simple specification or maybe data insertion. BL would be required when you have some business rules around these objects, ex: Deleting an object should check some specific condition before deleting the object etc

Ankur
  • 33,367
  • 2
  • 46
  • 72
  • Thanks for your answer, indeed there are no real rules about whether to delete an object or not. But is there a security issue or anything like that if I talk to the repository directly? – Julian Aug 12 '11 at 11:23
  • I don't think there is any "security issue", rather it makes your code simple without the overhead of additional layers in-between – Ankur Aug 12 '11 at 11:24
  • Ok seems logical, thanks for your oppinion Ankur, I would like to wait for some more oppinions so I won't accept the answer yet. Thanks! – Julian Aug 12 '11 at 11:26