Model 模型、业务规则和持久性

我很难找到适合某个应用程序的最佳方法。我并不真正习惯于取代旧TLA（三层体系结构）的新体系结构，所以这就是我的来源

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

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

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

如果（1）和（2）为false，那么模型应该在类上公开复杂的操作，而不是所有的实体属性都应该公开，我如何使用LINQ to SQL和sqlmetal创建模型类？我看到一些示例使用分部类来扩展模式实体的功能，但这将导致暴露实体细节（因为它只是一个扩展）

如果（2）为false，那么使用sqlmetal和LINQ作为ORM的最正确方法是什么？我使用sqlmetal提取模式，LINQ选择实体，然后是什么？根据数据库中的内容创建新实体

在我的研究中，我发现来自MVVM的VM和来自MVP的p有些相似。演讲者的职责是什么？还有ViewModel的视图？我将重点放在这两种模式上，因为它们将视图与模型完全隔离，这是我更喜欢的一个方面

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

---

我希望我能使问题足够客观。为了简化回答，我对我的疑问做了解释，但我担心这会使这篇文章有点太大。无论如何，非常感谢您的阅读，欢迎您提出任何建议

根据我的经验，我了解到模型很快就会过时，尤其是随着细节和复杂性的增加。此外，过分关注开发详细的建模工件可能会降低团队为客户提供增量价值的能力。因此，我建议您考虑一种敏捷的方法来生成模型，该模型为团队提供足够的细节，以便他们能够在大约2-4周的迭代中向客户提供有价值的特征。看看Scott Ambler的方法论。

根据我的经验，这里有一些关于模型设计的想法

放松。无论你在模型设计中做了什么，它仍然会受到人们的批评和抱怨。你不能取悦所有人。如果你让它完全符合最新的流行语思维，它可能是复杂的、抽象的或难以理解的。另一方面，如果你只是毫无理由地把它拼凑在一起，你也会因此陷入麻烦。代码是为应用程序服务的，它使应用程序以一种易于阅读、易于理解、易于维护的方式进入“完成”篮子。许多其他的考虑是次要的

要进行的暴露级别。正确的答案取决于你的应用程序的未来是什么，并且任何一种方法都可能是一个好的决定。帮助我决定如何处理模型的方法是假装我正在编写多个位于模型之上的consumer/user/UI层。因此，通常一个应用程序只有一个UI。但假设应用程序将有不止一个用户界面——比如说一个web用户界面和一个智能手机实际的用户界面。假装两者都存在将帮助您做出决策，将越来越多的逻辑放入模型/数据访问层，而将越来越少的逻辑放入UI层。如果您使您的模型非常精简，并将ORM的各个方面公开给UI，那么您就会尝试在UI中放入大量ORM类型代码。这可能导致代码更加精神分裂。这使得如果你决定改变后端，比如从SQL到另一种风格的SQL，或者Cassandra，或者其他东西，你几乎不能

考虑使用Web服务进行数据访问。您可以将所有数据访问放到Web服务中。然后您的UI层将使用webservice进行所有数据访问，包括读和写。这听起来有点激进，但它有一些关键的好处。

• 它帮助您分离UI层和业务逻辑层的关注点
• 它使您能够在以后添加更多的用户界面类型，所需的工作量相对较小。您可以将工具构建到您的平台中（如果它们还不存在的话），这样做非常容易，您可能会发现您的代码变得更小
• 它使得完全改变后端的工作方式而不改变任何UI代码变得相对简单

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

我想你担心错了