模型，业务规则和持久性

Question

我无法确定某个应用程序的最佳方法。我并不习惯那些取代旧TLA（三层架构）的新架构，所以这就是我来自的地方。

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

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

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

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

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

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

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

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

Answer 1

根据我的经验，以下是关于模型设计的一些想法。

1. 放松。无论您在模型设计中做什么，它仍然可以受到人们的批评和抱怨。你无法取悦所有人。如果你完全按照最新的思维方式使它成为流行语，那么它可能是复杂的，抽象的或难以理解的。另一方面，如果你只是在没有太多押韵或理由的情况下把它打成一片，那么你也可能会遇到麻烦。代码是为应用程序提供服务的，它使应用程序以易于阅读，易于理解，易于维护的方式进入完成的篮子。许多其他考虑因素都是次要的。
2. 要做什么级别的曝光。正确的答案取决于您的应用程序的未来，并且任何一种方法都可以是一个好的决定。有助于我决定如何处理模型的东西是假装我正在编写多个消费者/用户/ UI层，这些层位于模型之上。所以通常一个应用程序只有一个UI。但假装该应用程序将拥有多个ui--同时表示Web UI和Smartphone实际的GUI UI。假设两者都将帮助您做出决策，将越来越多的逻辑放入模型/数据访问层，并在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)方法论。