2

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

  1. 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?

  2. 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.

  3. 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
  • 2
    One sure way of making your BLL not reusable is to bind it to a particular database technology, and the best way to do that is to put everything in Stored Procedures. If you know you're going to EF, it may not matter (EF supports SP's). Sep 19, 2014 at 17:18
  • Thanks Robert. I was almost gonna submit this question under this forum, but I saw questions like these being asked on stackoverflow as well.
    – Pavitar
    Sep 19, 2014 at 17:25
  • 1
    Are there any apps or outside systems that rely on the stored procedures? If someone has an Excel spreadsheet pulling data from a stored procedure, it could be difficult to convert that to your c# code.
    – JeffO
    Sep 19, 2014 at 20:41
  • We've used SSRS which exports to spreadsheets.
    – Pavitar
    Sep 20, 2014 at 3:52

2 Answers 2

1
  1. 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.

  2. 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.

  3. 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
0
  1. It's up to you
  2. Use trace bullets, a POC
  3. 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!

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.