UI设计模式

Question

我一直在阅读MVP，MVVM，并在几个实践项目中使用了asp.net MVC。这些模式通常被称为UI模式，这对我来说有点混乱，因为我以前认为只有Views（在MVC中）是UI，Model是数据访问层+ BLL。 我的问题是，如果我使用实体框架（EDMX）作为我的模型，为什么我需要有一个单独的数据访问层（DAL）以及此数据访问层在这种情况下实际执行的操作。

Answer 1

实际上，视图和控制器都处理UI。基本上，除了Model Layer之外的所有内容都适用于UI。而且你必须明白，像REST API这样的东西也只是一种不同类型的用户界面。

至于你的研究，我会建议你采取更严格的模型2 MVC和HMVC看看。前者是最接近古典MVC的东西，你可以为网络做。后者具有非常有趣的用例，并解决了可重用性问题（并且在分布式系统中也有一些潜力）。

现在是主要问题。

您从数据访问逻辑分离领域的业务逻辑（域对象）（在datamappers），因为您将获得以下功能：

• 代码脱钩，关注点分离
• 能力单元测试独立地

基本上，这可以让你有代码库，其中添加一个特定的变化（如添加缓存或模型级授权检查）不需要你重写整个代码库。

此外，存储机制本身变得更加灵活。您可以轻松更改特定域对象的数据存储位置。例如，您可以将用户详细信息和身份验证移至noSQL数据库。这不会对您的业务逻辑的运作产生任何影响。当你在较大的团队中工作或维护旧代码时，这成为一个关键问题，因为很难掌握整个系统并保持这些知识是最新的。

至于数据访问层做什么：它需要域对象（包含域业务逻辑的东西），并存储来自它们的数据或为数据源层检索信息。

另外，我建议研究/手表：

• SOLID principles
• Unit testing（我会建议看全部来自清洁守则会谈讲座）

_{免责声明：我的主要语言是PHP，并且只在web上下文中具有MVC相关模式的经验（主要与它的Model2变体，因为Web本身的明显限制），它已经塑造了MVC结构的my understanding。}

Answer 2

MVC和其他人被认为是用户界面/表示模式，因为他们的主要任务是接受来自外部源的请求并显示结果。这些模式的M部分通常是指用作帮助填充视图（也称为视图模型）的DTO（数据传输对象）的简单模型。

业务逻辑，如果它比只是CRUD操作更强烈，通常与此分开。这允许不同类型的前端应用程序（这里是一个MVC网站，一个实际的手机/平板电脑应用程序）以不同方式与数据进行交互。

换句话说，MVC和类似的东西实际上只是真正做东西的商业逻辑之上的皮肤。

您需要问问自己，将EF部分与项目其余部分分开是否合理。如果你对数据做的不仅仅是CRUD操作，我会说是。

Answer 3

您不明确需要单独的DAL，因为EF是您的数据访问层和模型在同一时间。如果你是我们POCO的模型，你需要一个图层来处理这些对象的持久性。所以如果你使用NH作为OR/M，那么你的模型只包含POCO对象而NH是你的DAL。 NH通常隐藏在一个单独的层中，但这并不是必须的。如果涉及GUI，则不会直接使用您的实体进行绑定等。MVVM为其引入了ViewModel，它用作GUI和Domain Model之间的层，并提供模型中所需的所有数据GUI。