Sometimes Business Logic and Repositories are used as a single term, or the functionality of these items are made in the same classes. When designing software I tend to put these completely separate. It has multiple advantages, and provides separation of concerns.
The main advantage is that your data-access layer (i.e. repositories) become ‘plug-able’. You can change the underlying data model without having to touch anything else of your application. When you add more separate types of data storage this also proves to be a big advantage. Most applications these days don’t just work with an SQL database, but also with a No-SQL solution (e.g. Azure tables), queues (e.g. MSMQ or Service Bus), a REDIS cache, and so on.
Using a separate storage layer you can split these different databases into different assemblies, making code more manageable. Also you can have different teams work on different parts of data storage.
So what’s the role of Business Logic you might wonder? It is nice you have your places where you can store and retrieve your data, but most of the time a user needs to perform actions. One action can have multiple tasks that needs completion. Business logic exposes the logical actions a user does to the rest of the software (like a WebAPI does), and performs all the steps it needs to do to do that action.
So let”s say you place an order, the user tosses the order in. Next the business logic changes the stock, creates an invoice, sends a confirmation email and sends an email to someone who needs to do the rest of what’s needed to make sure the customer gets his order. Clearly these are multiple tasks that come out of one click of a ‘submit’ button. Business logic handles all the steps, repositories store and retrieve data.
How you stick this together? That’s another blog post 🙂