我对使用实体框架很陌生。我正在开发一个 Web MVC 2 项目（用于 .NET 3.5）并且正在探索使用实体框架，因为我读到它是使用数据访问层时推荐的方法。
我的问题是，我已经创建了我的数据库并使用 Visual Studio 创建了实体模型。现在，应该是，有自动生成的类供我使用。我浏览了一些教程，他们直接使用这些教程。
但是我不确定。展望未来，我正在考虑为我的模型添加一些额外的业务逻辑。那么我是否应该尽早创建自己的模型类？
提前谢谢你！
【问题讨论】：
标签： c# asp.net-mvc entity-framework
我认为您的意思是您已经通过设计器生成了模型。无论您使用 Code First Approach（首先创建类）还是 Database First 方法都没有关系。模型是您的表的表示形式，您可以通过 Dbcontext 访问模型，其中您的模型表示为 DbSet。您可以使用 dbcontext 根据实现的逻辑对模型/表进行任何类型的操作。
业务逻辑不应该是模型的一部分，最好是远离模型的两层。业务逻辑层应调用数据访问层（DAL），DAL 应具有通过 EF 中的 dbContext 访问/操作数据的逻辑。
请参阅存储库模式。 (https://msdn.microsoft.com/en-us/library/ff649690.aspx)
这有助于业务逻辑独立于底层数据源（无论是 sharepoint、sql server 还是 Web 服务），因为 DAL 层具有访问数据的实现。这种方法还避免了代码重复，有助于数据集中，并且不太容易发生错误。添加关注点分离也有助于更好的单元测试。
【讨论】：
您的数据模型代表您的数据库表。模型不应包含业务逻辑。您可以根据需要使用其他模型来组合您的 dbmodel 属性。在单独的类中应用您的业务逻辑。 服务，存储库这些概念用于使项目更易于管理。 但是你不应该在你的模型类中应用业务逻辑..这不是一个好习惯..
你可以从这里得到一些想法..这可以帮助你理解.. https://softwareengineering.stackexchange.com/questions/213317/net-mvc-project-architecture-layering
【讨论】：
这取决于发展中国家。
如果您的项目非常简单，并且您知道它永远不会变得复杂，那么可以不创建业务逻辑层。
此外，直接访问控制器中自动生成的类将使您的实现速度更快。
如果您没有这些确定性，那么我建议您创建一个业务逻辑层并使用自动生成的类，就像它们是要填充和持久化您的业务逻辑模型的数据库表一样。
如果您不创建业务逻辑层，您将在维护和扩展应用程序时受到影响。
【讨论】：