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