自制SQL模型 vs ORM？
我读过 Stack Overflow 关于 ORM 优缺点的讨论，有不同的观点。我想描述一下这个特殊的案例。
- 基于 LAMP 的中型 Web 应用程序，内部有一些意大利面条代码。
- 尽管有带有嵌入式模板的控制器和弱模型类分支，但代码距离 OOP 还很远。
- MySQL 有几十个表，大约几千个文件。
- 缓存，针对带索引的 MySQL 查询性能进行了调整。
- 每月浏览量约为一百万次。
- 用户大多具有读取权限。
我的问题是：
是否值得实现 ORM（Doctrine2 或 Propel），或者我应该限制自己从头开始编写模型类（类似于 ActiveRecord 模式，按表分组方法/查询和记录，因此每个实体都有两个相关的类）？
主要目标是：
应用程序性能，
易于代码/查询可读性和修改，以及
易于可能的数据库（详细信息）修改。
我个人更喜欢第二种选择；有相当复杂的 SQL 查询，我怀疑 ORM 是否能够维护所有查询的数据库抽象。初期开发已经结束，不需要快速开发代码/查询代码。对我们来说，能够轻松阅读、理解和修改代码/查询更为重要。
另一方面，在给定条件下使用 ORM 可能有一些我错过的优点。
I've read Stack Overflow discussion about ORM advantages and drawbacks, and there are different opinions. I would like to describe this particular case.
- LAMP based medium scaled web application with some spaghetti code inside.
- The code is quite far from being OOP, though there are controllers with embedded templates, and weak model classes branch.
- There are several dozen MySQL tables, and about thousand files.
- Caching, tuned for performance MySQL queries with indicies.
- About a million views per month.
- Users have mostly read access.
My question is this:
Is it worthwhile to implement an ORM (Doctrine2 or Propel), or should I limit myself to writing model classes from the scratch (similar to ActiveRecord pattern, group methods/queries by table and record, so each entity has two related classes)?
The primary aims are:
application performance,
ease of code/queries readability and modification, and
ease of possible DB (details) modification.
Personally I prefer the second choice; there are quite complex SQL queries, I doubt an ORM would be able to maintain DB abstraction for all queries. The initial development is over and there is no need for rapid speed of development of code/query code. It is much more important for us to be able to read, understand and modify code/queries easy.
On the another hand, there could be some strong points in ORM use for given conditions that I miss.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
构建你的代码肯定会对你的 2 和 3 有所帮助，如果做得好，1 也不应该受到影响。当您合并第三方 ORM 时，应该更容易实现良好的性能，因为这些 ORM 支持“开箱即用”的功能，例如缓存和延迟加载。
我建议您尝试小步重构应用程序，同时添加新功能或解决错误，从而避免难以证明和管理的大型重构项目。
我想说，使用第三方 ORM 的一个好方法是以类似的方式组织现有的代码和查询。因此，您可能会引入 ProductRepository 类，该类具有封装现有查询并返回 ResultSet 的 find() 方法。接下来，您应该引入产品数据类（只有字段而没有方法的类）。产品类应映射数据库中的产品表。现在 find 应该返回产品数组。 find() 方法现在将首先将 ResultSet 转换为 Products 数组并返回该数组。客户端代码应进行相应修改。最后，您开始将 find() 方法中的自定义查询替换为 ORM 委托。使用存储库的客户端不应检测到更改。 Product 数据类是模型层的种子。随着您的继续，您可以向其添加行为并创建一个真正的域层。
回到你的问题，我想说你首先以自定义 Active Record 的形式对现有代码进行分组（我建议使用 Repository，但最终这只是组织的问题），然后引入 ORM。所以，这不是非此即彼的情况，而是重构的第一阶段和第二阶段。
我会通过以下方式解决这个问题：
实现成熟的、可重用的 ORM 是一项艰巨的工作，因此我建议您合并现有的 ORM，并开始逐步引入它。
我在我的《C# 专业重构》一书中详细描述了这种方法，您可以下载示例代码，它将引导您完成 此处。
Structuring your code will definitely help you with 2 and 3 and if done right, 1 shouldn’t suffer either. As you incorporate third party ORMs, good performance should be easier to achieve since these ORM support features like caching and lazy loading “out of the box”.
I’d suggest you try to refactor your application in small steps, simultaneously with adding new features or resolving bugs thus avoiding huge refactoring projects that are difficult to justify and manage.
I’d say that a good way towards using third party ORM is to organize your existing code and queries in similar manner. So, you might introduce ProductRepository class that has the method find() encapsulating existing query and returns a ResultSet. Next, you should introduce Product Data Class (class with only fields and no methods). Product class should map the Product table in the DB. Now find should return array of Products. The find() method will now convert a ResultSet to array of Products first and return the array. Client code should be modified accordingly. Finally, you start replacing your custom queries inside find() method with delegation to ORM. Clients using Repository should not detect the change. The Product data class is a seed of your model layer. As you go on, you can add behavior to it and create a real domain layer.
Going back to your question, I’d say you first group your existing code in a form of custom Active Record (I suggest Repository, but in the end it’s just the question of organization) and then you introduce ORM. So, it’s not either-or situation, but first and second stage in refactoring.
I would approach this in the following way:
Implementing fully fledged, reusable ORM is a lot of work, so I’d suggest you incorporate existing one and start introducing it in small steps.
I have described this approach in quite a detail in my Professional Refactoring in C# book and you can download the sample code that will lead you through here.