Most of it was written 4-5 years ago. Our teams long term objectives are to use Entity Framework. Though we aren’t gonna do it right away as our deadlines aren’t allowing us to do so.
Now we have our own framework. I want to be able to segregate the Business logic layer in such a way that it need not be re-written when we move to EF. Please guide us with best practices, advise us in this direction.
Our business logic layer is very fragmented today (UI Code Behind + Stored Procedures/functions SqlServer/ C# persistent classes) : What if I want to segregate it totally and draw a very prominent line between Storage | DAL | Business Logic | UI
-
I want to know if it’s ok to move the BLL totally in SQl stored Procedures or does it have to be totally C# classes?
-
Also to avoid re-writing the BLL as we are going to move to EF eventually. What steps should I take so that I can readily use the entire BLL with EF without changing the code.
-
A lot of the stored procedures (which have the BL) lie in the storage DB itself. Does segregating the BLL mean the SP’s and functions should be in a different database altogether? or for all practical purposes it’s ok for them to be in the same DB?
I’ve seen multiple questions on SO which were really helpful, but I just couldn’t get a clear picture of the solution or advise I seek, so I put everything in one post.
Please correct me if I’m wrong. I’m a novice when it comes to system design. I wanna be able to foresee what I’m getting into before actually implementing it.
4
-
I think logic should always stay as much as possible in your application code. The application code is version controlled but your DB is not. If you have some code that relies on some logic in your DB, you might run into trouble later on. So if you’re not changing your DB to some major state, keep your logic in your application code.
-
Just refactor your DAL but don’t change interface/functions or how the BLL communicates with the DAL. This way you can easily switch to EF without refactoring your BLL. And when refactoring, always think of the SRP and don’t think too big. You don’t need to rewrite everything at once, just take a small portion at a time.
-
It’s ok for them to be in the same DB, but like I wrote before, try to move them into your application code. Most of the logic should be there, except some major state change of your DB, then it’s ok for it to be in a Stored Procedure.
1
- It’s up to you
- Use trace bullets, a POC
- n/a
If the long term goal is to use EF, then move to EF now. If the mangers don’t get the benefits then try convincing then really hard! Buy them books and so on…
If you do not know how EF fits your solution? Make a POC on a small part of the system (one use case), but make sure it’s implemented through all the layers of your application. Then you will know how EF fits you and you might have a better understanding on the scope to use it all together. You should be able to do this without affecting the deadline.
Good luck!