Hey!!
So I am at the first chapter, and I bumped into this phrase in context of single reponsibility principle.
Well not that I am a big expert in SP (stored procedures) but I went to check all the other devs that really adore them, and they pointed out some interesting pros like Security and Performance.
What do you think about this?
This seems to be a matter of preference. The author points out why he doesn’t like stored procedures. He wants separation of concerns. He wants his database to be about storing data and executing that task perfectly so he prefers to keep business logic out of the database.
You can form your opinion on this once you get more experience.
Good luck!
@Yuval_Lombard From the lesson,
Stored procedures enable us to add business logic to the database, which is always a big no. What if, in the future, we want to plug in a different database? Where do we take the business logic? Do we take it to the new database? Or do we refactor the application code and squeeze in the stored procedure logic somewhere?
A database should not hold business logic. It should only take care of persisting the data. This is what the single responsibility principle is, which is why we have separate tiers for separate components.
Hey - a follow up.
So storing business logic in the database is bad ?
Well the data structure is due to the Business logic ? right?
So how can you avoid business logic from persistence?
Maybe what you are saying is don’t process data …in that “stored procedure” encapsulation?
So I hv 2 questions
- would you need to process business logic on data/records /documents and store them back? into Modified or Newer records? I think that’s unavoidable.
- What better alternative exists? please? (stored procedures are perfect for this …logical processing ! why? coz you hv to process and you want to process fastest). Either way, even if you have another layer / logical tier …pulling, processing and restoring data …that logic exists and is documented and is maintained and is ported/migrated …when you do change that processing (whether you change the DB type or not), the maintenance, extensibility rework stays and is not eliminated? no?
Could you please help, elaborate?
Hi @Nay_Nirvana, Your keen interest is much appreciated 
In the lesson, the author points out why he/she doesn’t like stored procedures it does not mean that storing business logic in the database is a bad choice. Obviously, we can’t avoid business logic from persistence.
Implementing business logic in the database have some pros and cons:
Pros:
- Centralization of business logic.
- Independence of application type, programming language, OS, etc.
- Databases are less prone to technology migration or big refactoring.
- No rework on application technology migration.
Cons:
- SQL is less productive and more complex for business logic programming, due to the lack of libraries and language constructs the most application-oriented languages offer.
- More difficult (if possible at all) code reuse through libraries.
- Less productive IDEs.
Multi-tier applications
If we’re talking about multi-tier applications, it seems pretty clear that business logic, the kind of intelligence that runs a particular enterprise, belongs in the Business Logic Layer, not in the Data Access Layer.
Databases do a few things really well:
- They store and retrieve data
- They establish and enforce relationships between different data entities
- They provide the means to query the data for answers
- They provide performance optimizations.
- They provide access control
Naturally, nothing is engraved in stone. Stored Procedures are suitable for a wide array of tasks simply because they live on the database server and have certain strengths and advantages.
- Business logic is the custom rules or algorithms that handle the exchange of information between a database and the user interface. Business logic is essentially the part of a computer program that contains the information (in the form of business rules) that defines or constrains how a business operates. We obviously need to process business logic on data/records /documents and store them in modified records.
- Best Alternative I would say that a typical, modern approach is to use an Object-Relational Mapper (such as Entity Framework) to create classes that model your tables. You can then speak to your database through a repository that returns collections of objects, a situation that is very familiar to any competent software developer. The ORM dynamically generates SQL corresponding to your data model and the information requested, which the database server then processes to return query results. It works very well, and much more rapidly than writing stored procedures and views. This generally covers about 80% of your data access requirements, mostly CRUD. The other 20% covered stored procedures, which all of the major ORMs support directly.
Hope it will help, Thank you.
1 Like
Well the data structure is due to the Business logic ? right?
I am not sure what you mean by this.
So how can you avoid business logic from persistence?
Business logic is not persisted. Data is persisted. Logic resides in the code.
Maybe what you are saying is don’t process data …in that “stored procedure” encapsulation?
No, I am not saying this. I am saying adding business logic in the database is not advisable.