模型、业务规则和持久性

Question

我无法为某个应用找出最佳方法。我不太习惯取代旧 TLA（三层架构）的新架构，所以这就是我的出发点。

在为我的应用程序（POCO 类，对吗？？）设计 Model 和 DAL 时，我有以下疑问：

1. 我的模型类应该只公开属性并实现规则验证吗？几年前我会实现类似于现实世界的类，所以如果我有一个 可以走路的人，我会创建这样的方法。现在，我检查的每个样本（MVC、MVVM 等）都有“哑类”，它们公开数据并在需要时验证这些数据。复杂的操作呢？它们是否应该以某种方式成为 VM 的一部分（我怀疑这是对的……）。

2. 当使用 LINQ to SQL 作为 ORM 映射器时，我应该在模型中公开实体的所有属性吗？例如，我的大多数实体都有一个 ID 列作为其主要列钥匙。这应该与模型或业务无关，只是我的数据库架构的实现细节。

3. 如果 (1) 和 (2) 为假，那么模型 应该 公开对类的复杂操作，而不是公开所有实体属性，怎么办我使用 LINQ to SQL 和 sqlmetal 创建模型类？ 我见过一些示例使用部分类来扩展架构实体的功能，但这会导致暴露实体详细信息（因为它只是一个扩展)。

4. 如果 (2) 为假，使用 sqlmetal 和 LINQ 作为 ORM 的最正确方法是什么？ 我使用 sqlmetal 提取架构，使用 LINQ 选择实体，然后什么？根据我在数据库中的内容创建新实体？

5. 在我的研究中，我发现 MVVM 中的 VM 和 MVP 中的 P 有点相似。 Presenter 的职责是什么？还有那些ViewModel？我主要关注这两种模式，因为它们将视图与模型完全隔离开来，这是我更喜欢的一个方面。

6. 在设计此类 [MVVM, MVP] 应用程序时有哪些方法？ 我应该开始考虑模型，然后是 {P，VM} 层，然后是视图？我知道，这更像是一个主观问题，但例子会很好。

我希望我能够使问题足够客观。为了简化回答，我对我的疑问添加了解释，但恐怕这会使帖子有点太大了。无论如何，非常感谢您的阅读，非常欢迎任何建议。

Answer 1

以下是我对模型设计的一些想法。

1. 放松。无论您在模型设计中做了什么，它仍然可能受到人们的批评和抱怨。你不可能取悦所有人。如果你让它完全符合最新的想法，它可能是复杂的、抽象的或难以理解的。另一方面，如果你只是没有太多的押韵或理由就把它拍打在一起，你也可能会惹上麻烦。代码是为应用程序服务的，它是为了让应用程序以一种易于阅读、易于理解、易于维护的方式进入完成的篮子。许多其他考虑是次要的。
2. 要进行何种程度的曝光。正确的答案取决于您的应用程序的未来，而任何一种方法都可能是一个不错的决定。帮助我决定如何处理模型的事情是假装我正在编写多个模型之上的消费者/用户/UI 层。所以通常一个应用程序只有一个 UI。但是假设该应用程序将有多个用户界面——比如一个网络用户界面和一个智能手机的实际 GUI 用户界面。假装两者都会帮助您做出决定，将越来越多的逻辑放入模型/数据访问层，而将越来越少的逻辑放入 UI 层。如果你让你的模型非常瘦并且将 ORM 的各个方面暴露给 UI，那么你会很想将大量的 ORM 类型代码放入 UI。这可能导致代码更加精神分裂。这样一来，如果您决定更改后端，例如从 SQL 更改为另一种风格的 SQL、Cassandra 或其他东西，您几乎无法做到。
3. 考虑使用网络服务来访问您的数据。您可以将所有数据访问权限放入网络服务中。然后，您的 UI 层将使用 Web 服务进行所有数据访问，包括读取和写入。这听起来有点激进，但它有许多关键的好处。
   • 它可以帮助您分离 UI 层和业务逻辑层的关注点。
   • 它使您能够以相对较小的工作量在以后添加更多用户界面类型。您可以将工具构建到您的平台中（如果它们尚不存在），这使得执行此操作变得非常容易，并且您可能会发现您的代码变得更小。
   • 它使完全改变后端的工作方式变得相对简单，而无需更改任何 UI 代码。

我以这种方式将应用程序从 SQL 移至 Cassandra。通过将所有数据访问分离到一个 Web 服务中，为该 Web 服务实现一个好的测试套件，然后重新实现该 Web 服务。之后，该应用程序变得更小更干净了。

我认为你担心的是错误的事情。将数据访问层/模型视为提供使您的 UI 尽可能易于实现的理想服务。想象一下这个理想的数据访问层会是什么样子，这会使工作变得容易。把那个界面删掉，然后让它活起来。它的内部外观并不重要。

重要的是应用程序必须完成，必须工作，并且必须可读且易于维护。就我个人而言，我不会为所有其他东西出汗。除非你的应用程序的一个关键要求是从内部看它会给人留下深刻印象，否则你会担心错误的事情。阅读其他人要说的话，并使用能引起您共鸣且有意义的内容，但如果您所阅读的内容对您的项目没有用处，请不要担心。

Answer 2

根据我的经验，我了解到模型很快就会过时，尤其是随着细节和复杂性的增加。此外，过于专注于开发详细的建模工件可能会削弱团队为客户提供增量价值的能力。因此，我建议您考虑一种敏捷方法来生成模型，为团队提供足够的细节，以便他们可以在大约 2-4 周的迭代内为您的客户提供有价值的功能。看看 Scott Ambler 的 Agile Model Driven Development (AMDD) 方法。