代码之家 › 专栏 › 技术社区 › David

基础结构:模型作为应用程序的外部来避免存储过程

future-proof architecture design-patterns

David · 技术社区 · 15 年前

我的想法是:

我完全鄙视存储过程,原因有很多:成本、可伸缩性和兼容性。

成本:我可以用一个好的mysql服务器的成本得到2-3个好的轻量级web应用服务器。
可伸缩性:我当然可以缓存查询结果,但在使用存储过程时,我失去了获得更精细的缓存粒度的机会,而且它将应用程序与始终使用mysql联系在一起(谁有钱将存储过程从mysql重新写入其他东西?)
兼容性:在某些情况下,list_foo_widgetsbyuser()存储过程可能不适合客户机123的需要。修改list_foo_widgetbyuser()的签名将是自杀性的…因此,我必须编写一个新的存储过程cl123_list_foo_widgetbyuser(),这样会导致疯狂或杀人的dba。

我的解决方案:

将模型从应用程序的存储库中取出,并将它们放入外部repo中。然后,每个应用程序都会有一个指向外部存储库的models/base子目录。然后在前面放置一个简单的工厂方法,比如getmodel(“fooWidgets”),它可以将baseFooWidget类作为实例返回,也可以将其作为特定于应用程序的子实例返回。这将允许单个应用程序继承foowidget的类,或者与liquabase之类的工具相结合,从而允许更大的可变性基础。

一个声音在我的后脑勺说这太容易了…我错过了什么?

参考文献: 我知道一个事实,php-kohana框架做了一些类似的事情,允许应用程序设计人员用附加的功能包装kohana的基本库,如果php可以做到,我看不到任何其他语言有问题。

1 回复 | 直到 15 年前

Abel 15 年前

摆脱存储过程是一个很好的想法,你的三个要点都很关键。

另一方面,php不容易实现结构化包装。我不是一个PHP瘾君子(更像一个C/JavaGee),但是解决这个问题的最佳方法是单独的数据库/域/访问/业务层。简而言之:

在底部:数据库。只有桌子,亲戚,就这样。
然后需要映射:表示表的简单对象。通常每个表一个对象。
接下来,需要处理这些对象的方法。大多数表都需要一个“get all”、“get by id”和“save”方法。理想情况下,这些模块会进入一个单独的模块,因此可以在不需要更改映射的情况下进行开发。
最后,您需要您的业务逻辑,它可以进入一个单独的层或在您的应用程序中。

这是一个简单的概述。我不知道你的解决方案是否是这个意思,但通常是这样的:分离关注点。如果更改数据库,只需更改映射。如果需要不同的结果集,则只需更改访问层。

可以帮助您完成这个过程的工具是hibernate(但是您需要javabridge),它是这个 ORM工具的选择,但有一点陡峭的学习曲线。对于php来说,doctrine似乎可以为您做很多事情。其他工具也存在。理想情况下,工具允许往返工程:如果您更改了某些内容,您将再次运行该工具(或更改某些内容),并且不会中断应用程序。