基础结构:将模型作为应用程序的外部模型，以避免存储过程
我的想法：
我绝对鄙视存储过程，原因有很多:成本、可伸缩性和兼容性。
- 的成本:我可以得到2-3个好的轻量级的web应用服务器，而一个好的MySQL服务器的成本。可伸缩性:当然，我可以缓存查询结果，但在使用存储过程时，我失去了获得更细粒度可缓存内容的机会，另外，它还将应用程序与始终使用MySQL联系在一起(谁有钱将存储过程从MySQL重写到其他东西？)，在某种程度上，list_foo_widgetsByUser()存储过程可能不适合客户机#123的需求。修改list_foo_widgetByUser()的签名将是一种自杀.所以我必须编写一个新的sproc cl123_list_foo_widgetByUser()，这样就会导致疯狂或凶杀的DBA.
。
我的解决方案：
将模型从应用程序的存储库中提取出来，并将它们放入外部回购。然后，每个应用程序都会有一个指向外部存储库的models/Base子目录。然后将一个简单的工厂方法放在前面，比如GetModel("FooWidgets")，它可以将baseFooWidget类作为实例返回，也可以返回特定于应用程序的子实例。这将允许单独的应用程序继承FooWidget的类，或者与某些工具(如Liquabase )相结合，从而允许更大的可变性基础。
一个声音在我的后脑说这是太easy...what了，我是不是错过了这里？
参考资料:我知道PHP框架在这些方面做了一些事情，允许应用程序设计人员用新增的功能包装Kohana的基础库，如果PHP能够这样做，我就不会看到任何其他语言有问题。
回答 1
Stack Overflow用户
发布于 2009-10-17 17:54:50
摆脱存储过程是一个很好的想法，你用你的三分精确地击中了钉子。
另一方面，PHP不容易允许结构化包装。我不是一个PHP成瘾者(更多的是C# / Java )，但是解决这个问题的最好方法是单独的数据库/域/访问/业务层。简言之：
底部是
- ：数据库。只有表、关系--仅此而已。
- 则需要映射:表示表的简单对象。通常每个表都有一个对象。
- 下一步，您需要处理这些对象的方法。大多数表都需要一个"get“、"get”和"save“方法。理想情况下，这些模块可以进入一个单独的模块，因此无需更改您需要的业务逻辑(业务逻辑可以进入一个单独的层或在您的应用程序中)，就可以开发mapping.
- Finally，。
这是一个简化的概述。我不知道您的解决方案是否意味着这一点，但通常情况是这样的:分离关注点。如果更改数据库，则只需更改映射即可。如果需要不同的结果集，则只更改访问层。
可以帮助您完成这一过程的工具是Hibernate (但是您需要JavaBridge)，它是ORM工具的选择，但有一些陡峭的学习曲线。对于PHP，看起来Doctrine可以为您做很多事情。其他工具也存在。理想情况下，工具允许往返工程:如果您更改了一些东西，您将再次运行该工具(或更改某些东西)，并且不会破坏应用程序。
https://stackoverflow.com/questions/1582723
复制相似问题
腾讯云开发者
