我如何写我的BLL使它可重用？

Question

大部分都是4-5年前写的。我们的团队的长期目标是使用实体框架。虽然我们不会马上做，因为我们的最后期限不允许我们这么做。现在我们有了自己的框架。我希望能够隔离业务逻辑层，这样在我们迁移到EF时就不需要重写业务逻辑层了。请用最佳做法指导我们，并向我们提供这方面的建议。

我们的业务逻辑层现在非常分散(+存储过程/函数后面的UI代码、SqlServer SqlServer/ C#持久类)：如果我想将其完全隔离并在存储/存储/业务逻辑/UI之间划出一条非常突出的界线，该怎么办？

1. 我想知道是否可以在SQl存储过程中完全移动BLL，还是必须完全使用C#类？
2. 另外，为了避免重写BLL，因为我们最终将迁移到EF。我应该采取哪些步骤，这样我就可以在不改变代码的情况下轻松地使用整个带EF的BLL。
3. 很多存储过程(有BL)都位于存储DB本身。隔离BLL是否意味着SP和函数应该在一个完全不同的数据库中？或者就所有实际目的而言，它们都在同一个DB中是可以的？

我看到了多个问题，这些问题确实很有帮助，但我只是无法清楚地了解解决方案，也无法提出我所寻求的建议，所以我把所有的问题都放在了一个帖子里。

如果我错了，请纠正我。在系统设计方面，我是个新手。在实际实现之前，我希望能够预见到我要做的事情。

Answer 1

1. 我认为逻辑应该尽可能多地保留在应用程序代码中。应用程序代码是版本控制的，但您的DB不是。如果您的DB中有一些依赖于某些逻辑的代码，那么稍后您可能会遇到麻烦。因此，如果您没有将您的数据库更改为某种主要状态，请将您的逻辑保留在您的应用程序代码中。
2. 只需重构DAL，但不要更改接口/函数或BLL与DAL的通信方式。这样，您就可以轻松切换到EF，而无需重构您的BLL。在重构时，总是要考虑SRP，不要考虑太大。你不需要一次重写所有的东西，一次只需要一小部分。
3. 它们在同一个DB中是可以的，但是就像我以前写的那样，尝试将它们移到应用程序代码中。除了DB的一些主要状态变化之外，大多数逻辑都应该存在，那么它可以放在存储过程中。

Answer 2

1. 由你决定
2. 使用追踪子弹，POC
3. 不适用

如果长期目标是使用EF，那么现在转移到EF。如果经理们没有得到好处，那就试着说服他们，那就真的很努力！给他们买书籍等等..。

如果你不知道EF如何适合你的解决方案？在系统的一小部分(一个用例)上创建一个POC，但要确保它是通过应用程序的所有层实现的。然后，您将知道EF如何适合您，您可能有一个更好的理解范围，以使用它的所有。你应该能够做到这一点，而不影响最后期限。

祝好运!