Last post Jul 12, 2014 05:20 AM by jammycakes
Jul 02, 2014 11:01 PM|Rodrigo C|LINK
I am creating an architecture for my project
Web - Angularjs
Webapi - My apis
Model - my Models
Data - My entity framework mapping - maybe the repository here too
Service - Communication with other apis and also for others to communicate with my system
BLL - Business
But one repository would not be a bll class?
If it is, I will not create the BLL layer and leave the repository in Data
Jul 03, 2014 02:08 AM|Mikesdotnetting|LINK
Repository is part of your data access layer. It is a Data Access Pattern. It does not belong in your business logic layer.
Jul 03, 2014 02:14 AM|Jalpesh P. Vadgama|LINK
Repository pattern will part of your data layer. You can call your repositories from your business classes(Here you can create service classes which will call repository)
There is a very good example how you can create Line of Business app architecture using angular and asp.net web api at following link.
Jul 12, 2014 05:20 AM|jammycakes|LINK
Most traditional .net developers opt for a separate business layer (where all your logic goes) and repository (for data access). For a different perspective, I'd recommend experimenting with Python's
Django framework -- its Manager classes are effectively a combination of BLL and repository.
Whether you combine the two or not depends on your views on unit testing data-driven applications and which O/R mapper you are using. The purist view is that your tests shouldn't touch the database at all, but that you should mock your data access layer.
Ideally, your ORM itself would be your Repository and you'd mock that, but I've found in particular that NHibernate is not straightforward to mock, my main stumbling block having been the way that it uses extension methods to implement its Linq provider, so
I had to wrap it in a lightweight Repository for mocking purposes. The pragmatist view is that you can and should use a test database, preferably with an option to use an in-memory database such as SQLite, and if you are happy to do it that way (bearing in
mind that these tests would be integration tests rather than unit tests) then it's perfectly feasible to combine the two into one.
One thing I would caution against however is an antipattern that I call the Anaemic Business Layer. This is a cousin of the
Anaemic Domain Model, and it's where your business "logic" classes contain no logic at all, but just pass data straight through from your presentation layer to your repository. The implementations
that I've seen often just copy data from one set of domain model classes to an identical set of classes in a different namespace. More often than not, the domain model itself is anaemic as well. If you find yourself doing this, it's an indication that either
you would benefit from combining your business layer and repository into a single layer, or else that you are putting business logic into your repository itself. Certainly it just adds friction without providing any benefits whatsoever.