我正在建立一个MVC解决方案，并尝试将其分解为逻辑项目。到目前为止，我有以下项目：
mvc层引用服务层，服务引用repo。所有三个都引用了域，以便我可以在它们之间传递POCO。
这种设置是否有意义，因为我将来可能会使用不同的表示层，这将再次通过服务层工作？
另一方面，我的Domain层是否允许我将一个ORM替换为另一个ORM而不会破坏？我是否正确地认为只要Repo层中的repo类实现接口，我就可以创建一组具有不同ORM的新的具体repo类？
我的DbContext是否存在于具有EF实现的Repo层？这是UoW会去的地方吗？
我的服务可以使用域POCO上的注释进行基本验证，还是应该使用Fluent验证等工具？
最后（！）为每一层创建一个单独的测试项目是否正确（如果适用）？
提前感谢所有帮助，
詹姆斯
答案 0 :(得分：1)
只要你确保你正在开发一个接口，而不是一个实现，这肯定会有效。
我们正在开发具有与您建议的类似架构的应用程序。
我们的表示层使用MVP，因此我们可以在ASP.NET Webforms和其他前端之间共享我们的演示者。我们使用ServiceFactory，它使用依赖注入来创建我们的服务。这可以是WCF客户端代理或直接服务。如果呼叫通过WCF或直接进行，演示者不需要现在。
在我们的服务层中，我们使用包装一组存储库的UnitOfWork。 UoW也是通过DI构建的。
我们使用Entity Framework并从中生成POCO对象。我们只选择不将POCO一直分享到演示/视图层，而只是在业务和服务层。从服务层到视图，我们使用自定义DTO。目前EF和UoW住在同一个项目中。我们可以将它们移动到另一个程序集并从那里加载它们但实际上它不会有任何区别（我们希望每次加载解决方案文件时都避免整个'项目数'爆炸）。
我们在POCO实体和服务层（将DTO映射到POCO并可以检查数据）中进行部分验证。我们还会在演示者和视图中的javascript中验证传入数据（以获得良好的用户体验）。我们目前不使用工具进行验证。
是的，我们为每一层都有一个测试项目。 我们测试演示者，服务和UoW /存储库。在我们的构建服务器上，我们运行继续集成，它在几个不同的设置中运行所有单元测试（在内存中，使用WCF对数据库）。
当然，如果你只测试你的Presenters，这也会遇到服务和数据层，但如果你模拟所有的依赖关系，你可以单独测试每一层（特别是对于另一层应该抛出错误或其他东西的情况，在模拟整个图层时要容易得多。）
我目前唯一关注的是测试实际观点。我们目前没有以自动方式测试它们。也许我们将使用Coded UI测试或一些JavaScript框架。