database - 使用数据库的设计模式

Question

我看到 99% 的设计模式示例(策略、工厂、装饰器等)都带有硬编码信息，每个产品都在不同的类中，等等。但是，在大多数现实生活中的应用程序中，主要是数据库的使用，我们知道为每个产品创建一个类或使用硬编码信息是不切实际的。

我知道它们都是例子，但我认为你从书本上学习后那是痛苦的:

Create classes for CheesePizza, VeggiePizza..and classes for stores NYStore, ChicagoStore

对于工厂模式……在现实生活中，所有这些比萨饼和商店都只是数据库中的行。

那么，在这种情况下，使用数据库和设计模式的最佳方法是什么？

1. 如果比萨饼和商店在数据库中，则不需要使用设计模式。
2. 使用设计模式，而不是为每个 Pizza 或 Store 创建一个类，只需创建一个从数据库(例如 DatabasePizza 和 DatabaseStore!)读取数据的类实现。

我了解设计模式对于支付业务的重要性，例如。 (现金、信用卡、比特币..)其中每一种支付类型都有独特的特化，并且业务不完全在数据库中(信用卡需要打印收据，比特币需要访问网络服务等)。

但我想问的是:在一家真正的比萨餐厅，价格、配料、浇头，所有这些都根据不同的地方(芝加哥、纽约......)位于数据库中，设计模式的使用真的是必要的吗？当大量业务位于数据库时，设计模式的使用自然会减少吗？

Answer 1

...and in real life all these pizzas and stores are just rows in database.

数据库是否检查不变量、业务规范或您的类提供的一些其他自定义规则(在 oop 术语中)？ 否。数据库只是大多数应用程序的存储。

这些行是根据您的域模型和业务逻辑进行智能且可靠的计算的结果。
设计模式可以帮助您构建可以涵盖所有这些业务规则的灵活代码。

we know that is impracticable to create a class for each product

设计模式只是对行为特化进行一些抽象，并不关心严格的数据性质。
事实上，如果创建了一个 ChicagoPizza 类，这是为了指定一些独特的特化，而不是简单地标记:“这个披萨是芝加哥披萨”。

我不知道有多少应用程序处理超过几十个与同一主题相关的对象，所有这些对象都有一些强大而独特的特化。

在创建模式的情况下(如你所提到的)，我会说如果你有这么多“对象”只是它们的“性质”不同，你应该以一种简单的 类型结束 属性(在基类上)映射到数据库中，而不是在这种情况下使用额外的子类。

我没有发现编程书籍上提到的内容与软件实际情况之间有任何差距。

您的领域模型(根据定义硬编码)应该几乎总是比数据库思维更受青睐。

总结:

I know they are all examples, but I think that is painful after you learn from a book

如果“例子”是与现实不同的意思，那么它们根本就不是例子。
它们只是可以制作的真实软件的一小部分。