我是asp.net MVC和EF的新手，如果我的问题不明确或不容易，请原谅。
我已经阅读了一些关于EF Code-First方法的教程，现在我正在尝试本教程Getting Started with EF using MVC。
使用Code-First方法我使用POCO类来定义我的数据库模型，数据库逻辑，数据库验证，UI验证和一些UI逻辑。因此，我可以在表示层中使用这些类（或对象），或者在处理Web服务（或JavaScript代码）时将它们用作JSON对象。
我的问题：这不是将某些逻辑混合在一起吗？我的意思是我不应该使用特殊的视图模型类进行演示，这些类应该具有UI逻辑和验证？
将POCO对象发送到视图（或通常是客户端）是一种好习惯吗？
最后，我需要一些关于如何整理项目图层或文件夹的指导？我看到很多方法，我对选择什么或我应该采用什么格式感到困惑？!!
答案 0 :(得分：2)
您不应在应用程序的更高层中使用数据实体。使用像Automapper这样的库，将数据从DAL转换/复制/复制到视图模型或业务类中。这样可以使应用程序的各层保持独立，并使最终用户隐藏数据库架构。
请记住，MVC只关注演示文稿，所有实际工作都应该发生在应用程序的其他层。我尝试保持图层独立，并使用一些胶水代码将它们捆绑到一个应用程序中。我可以在处理MVC项目时编写数据访问和业务逻辑层，然后在命令行实用程序中重用。有很多关于编写质量代码的书籍。我个人认为Clean Code，Code Complete 2和Design Patterns非常有帮助。
答案 1 :(得分：1)
正如LeffeBrune所说，将数据实体直接显示到表示层是不好的做法，您可以尝试以项目服务的形式公开一些接口，将视图模型返回给控制器。这有助于保持图层分离，并实现工作单元模式和其他一些很酷的东西。
你可以开始阅读Scott Millet Book
ASP.NET设计模式
是设计好的分层应用程序的起点，here他的博客。
答案 2 :(得分：1)
您可以在业务层中定义您的EF实体可以实现的接口;业务逻辑不了解实际的实现。为此，您需要数据层来引用业务层，这意味着您要反转依赖项 - 然后使用IoC容器将接口绑定到它们的实现。 ......但是，这是许多方法中的一种。
问题是，考虑到单一责任，你的实体不应该担心UI的东西 - 这可能意味着你的接口也需要通过“视图模型”类来实现，这些类实现了一些东西像验证和其他业务＆amp;演讲问题。
答案 3 :(得分：1)
您的问题需要进行大量讨论。
为项目选择基础架构是一个复杂的问题，取决于很多因素。有一些设计模式可以满足项目中的不同需求，这些需求涉及您或您的团队的多种概念和技术。我建议您使用两种有价值的资源来帮助您了解专注于.Net技术的软件架构。
总而言之，视图模型，POCO，层等是在软件架构中扎根的概念，我相信它们不能简单描述。
答案 4 :(得分：0)
我通常使用的是在我的数据访问中使用的POCO层和在我的视图中使用的视图模型层，就像LeffeBrune所说的那样。 我的所有图层都使用POCO，控制器负责构建每个视图所需的视图模型。 为了使这项工作更加自动化，我使用了automapper。 所以我的解决方案结构通常是这样的：