模型、业务规则和持久性

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

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-4周的迭代内为您的客户提供有价值的特性。看看斯科特·安布勒的 Agile Model Driven Development (AMDD) 方法论。