DAL（数据访问层），模型层，EF（实体框架）代码优先和业务逻辑，它们如何相互配合？
DAL（数据访问层），模型层，EF（实体框架）代码优先和业务逻辑，它们如何相互配合？
逐渐地，我对ASP.NET MVC4的理解和熟练程度越来越高。然而，我仍然对这个非常重要的问题不够清楚。假设我有一个模型：
public class WorkPaper
{
public int WorkPaperID { get; set; }
public string name { get; set; }
public string description {get ; set; }
public bool verified {get; set;}
public DateTime dateAdded {get; set;}
}
我使用这个模型与Entity Framework的代码优先方法，并且我有以下的数据库上下文：
public class NicodemeContext : DbContext
{
public DbSet Workpapers { get; set; }
}
我不明白的是：什么是模型层，什么是数据访问层。对我来说，WorkPaper类倾向于属于数据访问层，因为我设计了它，并选择了属性的名称和类型（导航属性等）以适应EF模式。但是问题是，如果我是正确的，我真的不知道应该把业务逻辑放在哪里。
在这种特定情况下，如果我想要添加一条规则，即如果一个工作文件未经验证，则不能发送；另外一条规则是，如果它在两周前已添加，则不能提交（奇怪的规则，但这只是一个例子）。我应该把它们放在哪里？我需要创建另一个类，但是我应该把它放在哪里，它应该包含什么？它不会和我已经有的类非常冗余吗？但另一方面，由于该类是“面向数据库”的，在那里添加业务规则是否会让它变得混乱？
我的重点真的是理解我应该把业务逻辑放在哪里，并理解数据访问层和模型层之间的区别。我很难区分数据访问层和模型层，因为它们在我看来非常相似。我想以正确的方式做事。（基本上，我不知道在MVC中应该在哪里编写“我的程序”！一旦我想编写我真正感兴趣的功能，我就感到不舒服。我觉得自己没有做对事情。）
在开发应用程序时，如何将DAL（数据访问层）、模型层（Model Layer）、EF code-first 和业务逻辑相结合，这是一个没有唯一“正确”答案的问题。这取决于个人的观点和应用的复杂程度。有些人建议在模型中同时处理业务逻辑和数据层实体，而另一些人则建议创建独立的实体对象、业务对象和视图模型对象。
如果你正在开发一个相对简单的CRUD类型的应用程序，那么按照某些人的建议，你可能不会遇到太多问题。然而，在更复杂的应用程序中，这种做法可能会遇到问题。例如，当业务逻辑与数据逻辑不同时会发生什么情况？如果将它们合并成一个实体集合，那么你就不得不在每个地方都使逻辑相同，否则就需要花费大量时间进行改造。
最灵活的方法是将Presentation、Business和Data层完全分离。这样，UI的需求不需要与其他层相匹配。（这里举一个简单的例子，假设对于某些对象，特定字段可以为null，而对于其他对象则不行。你的数据层只需要知道该字段是可空的，而业务层则需要知道某些对象不能为null）。
然而，这种方法可能会带来很多额外的工作量，并且在每个层中需要看起来是重复的代码，这会增加很多额外的工作量，对于小型或简单的应用程序来说往往不值得。
要记住的一点是，MVC是一种表现层模式。这意味着它仅关注用户界面。模型通常被认为是“视图模型”，即视图使用的模型。这个模型根据视图的需求进行定制。例如，通过使用数据属性，你可以在数据模型上不会放置的属性。
如果你认为MVC严格属于表现层，那么MVC并不关心你使用的数据访问方式，也不关心你使用的业务层是什么样的。它可以是一个服务层，或者一个仓储层，或者是一个业务对象库（例如CSLA）。
在MVC应用程序中，通常使用某种类型的服务层，或者如果只是进行CRUD操作，则使用仓储层。每个层之间通常使用像AutoMapper或自定义构建映射类这样的技术进行映射。
重要的是要明白，MVC不关心业务逻辑和数据逻辑，所以不要为它们在MVC应用程序中的结合而感到困惑。除了基本的接口之外，它们并没有什么关系。
你的应用程序是一个由对象组成的集合，可以看作是一个架构。这个架构由不同的层组成，包括MVC、服务、数据等。MVC可能是主要的用户界面，但这并不意味着其他一切也是MVC。
感谢Erik的回答！你清楚地理解了我的问题，你是对的，我也对MVC的角色感到困惑。在我看来，MVC应用程序中的一切都是MVC。非常感谢你的回答，多亏了你的解释，我感到更加自信。这正是我需要的解释！
很好的答案。特别是没有总有一个“正确”的方法。这确实取决于具体情况。