我正在寻找一些关于从Asp.Net WebForms迁移到MVC的策略的建议。我目前有以下格式的大约60个项目的解决方案：
解决方案
所有数据模型都是使用数据库优先（.edmx）和T4模板的实体框架6。数据访问代码在Business和Web（WebForms）项目之间混合使用。代码库最初从一个开发者到一个小团队有机地发展，这解释了SOC方面的一些不良做法，但是我们想借此机会来纠正这个问题。
我想开始转向完整的MVC解决方案，并且感觉要做的第一件事就是确保当前驻留在Web项目中的任何数据访问逻辑都被推送到业务层以获得分离关注点。研究这方面的最佳实践使我走向了工作单元和存储库模式，但是进一步的阅读似乎暗示这是过度的。
使用当前的Web窗体模型重构我的业务和数据层的最佳方法是什么才能为MVC做好准备。其次是迁移到MVC的接受方法，将View引入现有的WebForms解决方案以创建Hybrid或创建新的MVC项目，引用我现有的BAL和DAL并从头开始构建应用程序UI？
关于实体框架，一切似乎都朝着CodeFirst方法发展。如果我们想要采用最佳实践方法，这是我们需要规划的吗？
我们目前是一个非常小的团队，我们希望尽可能地尽可能地重复使用我们现有的项目，并尽可能地重构，以便开始向MVC迈进。
对于我如何开始接近这一点的任何想法都表示赞赏。
由于
答案 0 :(得分：1)
你有讨厌的应用程序。对于rembmer来说，首先，MVC是一种UI模式。所以在一个设计合理的应用程序中，从WebForms到Mvc的swtich只意味着改变UI层。
我想开始转向完整的MVC解决方案，并且首先要确保当前驻留在Web项目中的任何数据访问逻辑都被推送到业务层以获得关注点分离
没有！数据访问逻辑应该在DAL中（提示：它是首字母缩略词），而不是BL，而不是UI。仅持久性。 BL和UI会要求DAL通过存储库保存/检索对象。顺便说一句，EF只处理数据库。不要错误地在Ef实体之上构建业务对象。一个模型的业务概念和行为，另一个模型数据库访问。它们通常不兼容。在处理除持久性之外的任何事情时，请忽略您拥有数据库或ORM。
为此研究最佳实践使我走向了工作单元和存储库模式，但是进一步的阅读似乎暗示这是过度的。
如果您有一个非常简单的应用程序而不关心维护它，那就太过分了。我知道很难相信，但可能超过80％（或多或少随机数）的开发人员仍然不明白如何正确实现存储库模式，这就是为什么它对他们变得无用。简而言之，repo 使用 EF，但它不是建立在它之上的。 repo'将'business / ui对象'转换为EF实体，反之亦然。
repo界面永远不会暴露IQueryable或者你首先使用db的事实。因此，没有通用的存储库，也没有EF实体的暴露。此外，Bl / UI不应该创建查询（这意味着他们知道数据是如何存储的--DAL实现细节），这是存储库的工作。更高层只告诉存储库他们想要什么，从不如何这样做。
其次是一种可接受的迁移到MVC的方法，将View引入现有的WebForms解决方案以创建Hybrid或创建新的MVC项目，引用我现有的BAL和DAL并从头开始构建应用程序UI？
虽然您可以在同一个项目中混合WebForms和Mvc，但最好不要这样做（减少头痛）。从头开始创建mvc应用程序，然后将Web表单页面移植到它。