c0d*_*0da 0 sql database orm database-design
我正在做一个需要频繁访问数据库,插入和删除的项目.我应该使用Raw SQL命令还是应该使用ORM技术？项目可以正常工作,没有任何对象,只使用SQL命令？这一般会影响可扩展性吗？
编辑:项目是用户未提供我的内容但用户生成内容,项目在线的类型之一.因此,内容的数量取决于用户的数量,如果项目甚至有50000个用户,而且每个用户都可以创建内容或阅读内容,那么最合适的方法是什么？
如果您对ORM没有(或有限)经验,那么学习新API需要时间.另外,你必须记住,牺牲速度为'魔术'.例如,大多数ORM将为字段选择通配符"*",即使您只需要表格中的标题Articles列表.
在特殊情况下,ORM将会失败.
从OOP的角度来看,大多数ORM(基于ActiveRecord模式的ORM )都存在极大的缺陷.它们在数据库结构和类/模型之间建立紧密耦合.
您可以将ORM视为技术债务.它将使项目的开始更容易.但是,随着代码变得越来越复杂,您将开始遇到由ORM API的限制引起的越来越多的问题.最终,您将遇到无法使用ORM执行某些操作的情况,并且您必须直接编写SQL片段并直接编写语句.
我建议远离ORM并在代码中实现DataMapper模式.这将使您在域对象和数据库访问层之间分离.
我想说最好尽可能以最简单的方式实现目标.如果使用ORM没有真正的附加优势,并且应用程序非常简单,我就不会使用ORM.如果应用程序真的是处理大量数据,并且没有业务逻辑,我就不会使用ORM.
这并不意味着您不应该设计您的应用程序属性,但是再次:如果使用ORM不会给您带来任何好处,那么您为什么要使用它？
| 归档时间： |
|
| 查看次数： |
3662 次 |
| 最近记录： |