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.