代码之家  ›  专栏  ›  技术社区  ›  Bruno Brant

模型、业务规则和持久性

  •  6
  • Bruno Brant  · 技术社区  · 14 年前

    我很难找到某个应用程序的最佳方法。我并没有真正习惯于取代旧TLA(三层体系结构)的新体系结构,所以这就是我的出发点。

    当设计 模型 以及 达尔 对于我的应用程序(poco类,对吧??),我有以下疑问:

    1. 我的模型类应该只公开属性并实现规则验证吗? 几年前,我将实现类似于现实世界的类,因此如果我有一个 谁能 步行 我会创建一个这样的方法。现在,我检查的每个示例(MVC、MVVM等)都有“哑类”,它们公开数据,并在需要时验证这些数据。复杂的操作呢?如果它们以某种方式成为虚拟机的一部分(我怀疑这是正确的…)。

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

    3. 如果(1)和(2)是假的,那么模型 应该 在类上公开复杂的操作,并不是所有的实体属性都应该公开,如何使用linq to sql和sqlmetal创建模型类? 我已经看到一些示例使用部分类来扩展模式实体的功能,但这将导致公开实体详细信息(因为它只是一个扩展)。

    4. 如果(2)为假,那么使用sqlmetal和linq作为ORM的最正确方法是什么? 我使用sqlmetal提取模式,使用linq选择实体,然后呢?根据数据库中的内容创建新实体?

    5. 在我的研究中,我发现来自MVVM的VM和来自MVP的P有些相似。A的职责是什么? 节目主持人 ?和那些 视图模型 ? 我将重点放在这两种模式上,因为它们完全将视图与模型隔离开来,这是我喜欢的一个方面。

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

    我希望我能使问题足够客观。为了简化回答,我增加了对我的疑问的解释,但我担心这会使帖子有点太大。不管怎样,谢谢你的阅读,任何建议都非常欢迎。

    2 回复  |  直到 11 年前
        1
  •  3
  •   Unoti    14 年前

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

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

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

    我认为你担心的是错误的事情。将数据访问层/模型视为提供理想的服务,使您的UI尽可能容易实现。设想一下这个理想的数据访问层是什么样子的,这将使工作变得容易。切断那个接口,然后使它活跃起来。从内部看,这并不重要。

    重要的是应用程序必须完成,必须工作,必须可读,易于维护。就我个人而言,我不会流汗。除非你的应用程序的一个关键要求是当从内部观察时,它能给人留下深刻印象,否则你会担心错误的事情。阅读别人必须说的话,使用你内心的共鸣和有意义的东西,但如果你所读的东西在你的项目中似乎对你没有帮助,不要为此而苦恼。

        2
  •  0
  •   johnnieb    14 年前

    根据我的经验,我知道模型很快就会过时,特别是随着细节和复杂性的增加。此外,过分关注开发详细的建模工件可能会降低团队向客户提供增量价值的能力。因此,我建议您考虑一种敏捷的方法来生成向团队提供足够详细信息的模型,以便他们能够在大约2-4周的迭代内为您的客户提供有价值的特性。看看斯科特·安布勒的 Agile Model Driven Development (AMDD) 方法论。