模型、业务规则和持久性

Question

我在为某个应用程序找出最佳方法时遇到了麻烦。我不太习惯取代旧 TLA(三层架构)的新架构，所以这就是我的来源。

在为我的应用程序(POCO 类，对吧？？)设计模型和 DAL 时，我有以下疑问:

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

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

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

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

在我的研究中，我发现 MVVM 的 VM 和 MVP 的 P 有点相似。主持人的职责是什么？那些 ViewModel 呢？ 我专注于这两种模式，因为它们将 View 与模型完全隔离，这是我更喜欢的一个方面。

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

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

Answer 1

以下是根据我的经验，为您提供有关模型设计的一些想法。

放松。 无论您在模型设计中做什么，它仍然会受到人们的批评和投诉。你不能取悦所有人。如果你让它完全符合对事物的最新想法，它可能是复杂的、抽象的或难以理解的。另一方面，如果你只是在没有太多韵律或理由的情况下把它放在一起，你也会遇到麻烦。代码是为应用程序服务的，它使应用程序以易于阅读、易于理解、易于维护的方式进入完成篮子。许多其他考虑是次要的。

什么级别的曝光做 .正确的答案取决于您的应用程序的 future 是什么，并且任何一种方法都可以是一个很好的决定。帮助我决定如何处理模型的事情是假装我正在编写多个位于模型之上的消费者/用户/UI 层。所以通常一个应用程序只有一个 UI。但是假设该应用程序将有多个用户界面——比如一个网络用户界面和一个智能手机实际的用户界面用户界面。假装两者都存在将有助于您做出决定，将越来越多的逻辑放入模型/数据访问层，而将越来越少的逻辑放入 UI 层。如果你让你的模型非常瘦并且将 ORM 的各个方面暴露给 UI，那么你会很想在 UI 中放入大量的 ORM 类型代码。这可能导致代码更加精神 split 。这样一来，如果您决定更改后端，例如从 SQL 更改为另一种 SQL 风格，或者 Cassandra 或其他东西，您几乎无法做到。

考虑使用网络服务进行数据访问。 您可以将所有数据访问权限放入网络服务中。然后您的 UI 层将使用 web 服务进行所有数据访问，包括读取和写入。这听起来有点激进，但它有许多关键的好处。

它可以帮助您分离 UI 层和业务逻辑层的关注点。

它使您可以稍后以相对较小的努力添加更多用户界面类型。您可以将工具构建到您的平台中(如果它们尚不存在)，这使这变得非常容易，并且您可能会发现您的代码变得更小。

它使完全改变后端的工作方式变得更加简单，而根本不改变任何 UI 代码。

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

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

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