关于重构业务/数据逻辑以准备将 WebForms 迁移到 MVC 的建议

Posted 2023-03-25

【中文标题】关于重构业务/数据逻辑以准备将 WebForms 迁移到 MVC 的建议

【英文标题】：Advice on refactoring Business/Data Logic in preparation for migrating WebForms to MVC

【发布时间】：2014-02-24 01:38:30

【问题描述】：

我正在寻找一些关于从 Asp.Net WebForms 迁移到 MVC 的策略的建议。我目前有大约 60 个项目的解决方案，格式如下：

解决方案

ProjectA.DataModel ProjectA.Business ProjectA.Web ProjectB.DataModel ProjectB.Business ProjectB.Web Framework.Core Framework.Common …等等

所有数据模型都是使用数据库优先 (.edmx) 和 T4 模板的 Entity Framework 6。数据访问代码混合在业务和 Web (WebForms) 项目之间。代码库最初从一个单独的开发人员有机地发展到一个小团队，这解释了 SOC 方面的一些不良做法，但我们想借此机会尝试纠正这一点。

我想开始转向完整的 MVC 解决方案，并且觉得首先要做的是确保当前驻留在 Web 项目中的任何数据访问逻辑都被推送到业务层以实现关注点分离。对此进行研究的最佳实践将我带到了工作单元和存储库模式，但进一步阅读似乎表明这是矫枉过正。

使用当前 Web 窗体模型重构我的业务和数据层以准备 MVC 的最佳方法是什么。其次是迁移到 MVC 的公认方法，将视图引入现有的 WebForms 解决方案以创建混合或创建新的 MVC 项目，引用我现有的 BAL 和 DAL 并从头开始构建应用程序 UI？

关于实体框架，一切似乎都在朝着 CodeFirst 方法发展。如果我们想采用最佳实践方法，我们是否需要对此进行规划？

我们目前是一个非常小的团队，希望尽可能地重用我们现有的项目，并尽可能地重构，以便开始向 MVC 迈进。

感谢您对我如何开始处理此问题的任何想法。

谢谢

【问题讨论】：

您可能感兴趣：blog.8thlight.com/uncle-bob/2012/08/13/…

感谢 Mik378 我会通过该链接阅读

> 一切似乎都在朝着 CodeFirst 的方向发展……是的，很重要。在过去的几年里。 Code First 是前进的方向。

顺便说一句，代码优先只是创建数据库的方式，仍然是一个持久性细节，与域/业务优先无关。所以 code first 是 database design first 但我们使用 code 而不是 vs Designer。

【参考方案1】：

你那里有讨厌的应用程序。无论如何，首先要记住的是 MVC 是一种 UI 模式。因此，在一个设计合理的应用程序中，从 WebForms 切换到 Mvc 意味着只需更改 UI 层。

我想开始转向完整的 MVC 解决方案，并且觉得首先要做的是确保当前驻留在 Web 项目中的任何数据访问逻辑都被推送到业务层以实现关注点分离

不！数据访问逻辑应该在 DAL 中（提示：它是首字母缩写词），而不是 BL，而不是 UI。仅持久性。 BL 和 UI 会要求 DAL 通过存储库保存/检索他们的对象。顺便说一句，EF 只处理 db。不要错误地在 Ef 实体之上构建您的业务对象。一个模型业务概念和行为，另一个模型数据库访问。它们通常不兼容。在处理持久性以外的任何事情时，请忽略您拥有 db 或 ORM。

对此最佳实践的研究使我转向了工作单元和存储库模式，但进一步阅读似乎表明这是矫枉过正。

只有当你有一个非常简单的应用程序而你不关心维护它时，这才是矫枉过正。我知道很难相信，但可能超过 80%（或多或少的随机数）的开发人员仍然不了解如何正确实现存储库模式，这就是为什么它对他们变得无用的原因。简而言之，repo 使用 EF，但它不是建立在它之上的。 repo 将业务/ui 对象“转换”为 EF 实体，反之亦然。

repo 接口应该从不暴露 IQueryable 或您首先使用数据库的事实。因此，没有通用存储库，也没有暴露 EF 实体。此外，Bl/UI 不应该创建查询（这意味着他们知道数据是如何存储的 - DAL 实现细节），这是存储库的工作。更高层只是告诉存储库他们想要什么，而不是如何去做。

其次是迁移到 MVC 以将视图引入现有 WebForms 解决方案以创建混合或创建新 MVC 项目、引用我现有的 BAL 和 DAL 并从头开始构建应用程序 UI 的公认方法？

虽然您可以在同一个项目中混合使用 WebForms 和 Mvc，但最好不要这样做（少一些麻烦）。从头开始启动 mvc 应用程序，然后将 Web 表单页面移植到它。

【讨论】：

感谢您的详细回复。我们将看看如何使用存储库和 UOW，并遵循您上面提到的一些最佳实践。到达那里可能需要更长的时间，但我们不妨借此机会把它做好。我们还将通过创建一个新的 MVC 站点来迁移 Web 表单，并采用这种方式。

@belfastdev 我也有类似的情况。你进展如何？我可以阅读任何好的参考资料吗？