ORM工具或手动构建对象到关系映射层

您最好的选择是确保无论您做什么,您都能在以后更改它。因此,如果您使用nhibernate或ef,您将希望对框架的实际依赖性保持在非常紧密的状态中;对于手动实现也是如此。

尝试实现存储库模式,然后您可以构建一个nh repo、ef repo等,看看哪一个最适合您的需求。

我个人的观点是做适当的或映射(无论是手工的还是框架的)——这里的含义是您的业务/域对象 不 就像你的桌子,反之亦然。ORM的关键不仅仅是将数据从数据库中取出并输入到应用程序中(数据集可以做到这一点),而是让您充分利用应用程序中OOP和后端RDBMS这两个方面的优势。

如果您只是使用SQL作为“哑存储”(我最喜欢使用它),那么您可以考虑使用OODB或其他对象持久性方法。在业余爱好/副业项目中,这总是一件有趣的事情——但这很难卖给管理层(他们失去了他们的SQL服务器),但这值得考虑。

当然,如果您谈论的是非常小的应用程序,那么也许您可以按照活动记录模式或者事务脚本模式来实现一些东西——XScript非常适合非常小的应用程序,但是不能很好地扩展——而活动记录非常适合数据输入/CRUD应用程序。

对于简单的应用程序,额外的映射层似乎是有利的,因为该工具可以处理简单的映射和SQL,因此节省了一些时间,但是当对象模型变得更复杂时呢?

事实上,我想说是相反的。

在具有复杂对象模型的大型应用程序中使用ORM更有意义:

• 对于具有简单DB模型的非常小的应用程序,ORM可能是杀伤力过大的,因为持久性层很容易实现,而不会在某个地方引入错误,ORM也不会为您节省很多工作。

• 另一方面,由于大型应用程序具有更复杂的数据库数据模型,因此 JOIN S和你的 UPDATE 错误等等,所以ORM可能真的很有用。

如果这是一个问题 “我是否应该使用ORM?” 然后对你的问题没有绝对的答案,每种方法都有利弊权衡,既有正面的,也有负面的。

ORM可以帮助您快速启动和运行,特别是如果您有一个更大的数据模型。如果您需要生成几个不同的持久性层,它们也可以是非常好的,因为您支持多个具有相同版本产品的数据库供应商。ORM并不像以前那么糟糕,它们现在相当有效。

就个人而言,尽管我不喜欢它们——我认为如果你对你的数据库技能半熟,那么你应该使用它们。我认为ORM倾向于保护开发人员不受数据库复杂性的影响,这不一定是件好事。我喜欢调整我的数据访问和存储,并且在编写代码将数据集映射到域对象时可能会很乏味,这不是很困难,也不是很容易出错,我知道 确切地 任何时候都在发生的事情,任何地方都不会发生魔法。如果存在性能问题或效率低下,那么我可以很快地跟踪并解决它们。

您可以构建自己的ORM映射工具。例如这里 http://askcodegeneration.com/php/generate-propel-schema-for-php-symfony/

推进ORM模式是从一个简单的描述类格式生成的(对于任何其他语言,如C和任何ORM框架,如Hibernate,事实上,在将来我打算这样做),没有什么可以阻止这样做:

class-list: [question answer user interest relevancy]

Sample-Model: {

  class question [

    Id: 0
    title: ""
    body: ""
    created_at: 'now
    updated_at: 'now
    user_Id: [User]

  ]

  class answer [

    Id: 0
    question_Id: [question]
    user_id: [user]
    body: ""
    created_at: 'now
    updated_at: 'now

  ]

  class user [

    Id: 0
    first_name: ""
    last_name: ""
    created_at: 'now
  ]

  class interest [
    question_id: [question]
    user_id: [user]
    created_at: 'now
  ]

  class relevancy [
    answer_id: [answer]
    user_id: [user]
    score: 0
    created_at: now
  ]

}