拥有业务逻辑层时仍需要模型层吗？

Question

在asp.net解决方案中，当你有一个Business项目时，你会对Model项目做什么？

在界面上，我发现使用映射到执行所有CRUD的类的objectdatasource非常容易和有效。我将该课程放在了Business项目的旁边。该类包含linq查询，用于从/向数据库获取和设置数据。

那么Model项目还剩下什么呢？界面与Business项目谈话很好。在这里可以做更多或更好的事情吗？

这里有更多问题，如果您使用Linq to SQL，那么您的数据访问层应该是什么？只有DBML文件？

我感谢您的时间和精力

祝你好运

Answer 1

普遍接受的最佳做法是使用查看模型模式。

视图模型基本上是业务对象的展平表示，对应于在特定上下文中查看业务对象。视图在视图模型的上下文中呈现，而不是将业务对象传递给视图。

虽然我可以用大量的代码示例来解释实现细节的实现，但这是毫无意义的，因为Jimmy Bogard already wrote "How we do MVC - View Models。您将更好地了解如何实施此方法，以及在审阅该文章后这样做的原因。

Answer 2

如果您正在使用ASP.NET MVC，那么我将执行以下操作：

拥有一个充当BLL和Controller之间接口的“本地”模型。本质上，控制器应该只知道您在本地使用的对象。

这可能涉及将代码映射到模型的“存储库”部分; AutoMapper就是一个很好的例子。

这有几个原因：

1. 您的控制器与BLL中的更改没有直接关系。
2. 测试的依赖性。如果您正在使用构建控制器的“One Controller Per Concern”方法，那么您的依赖关系就会少得多。如果你将这些类和依赖项直接引入控制器，这会变得有点毛茸茸，因为那时你必须进行更多的模拟，并且你可以让测试失败，原因不是很明显。

Answer 3

如果你真的需要，你不会需要：P。模型文件夹主要放在新的MVC项目中作为指导，以展示如何与MVC分离关注点。如果您的业务层已在另一个项目或其他文件夹中，则可以将其删除。该文件夹在MVC架构中没有特殊含义。