为什么所有的活动logging都讨厌?

随着我越来越多地了解面向对象,并开始实施各种devise模式,我不断回到人们讨厌活动logging的情况 。

人们经常说它不能很好地扩展(引用Twitter作为主要例子),但是没有人真正解释为什么它不能很好地扩展; 和/或如何在没有缺点的情况下实现AR的优点(通过类似但不同的模式?)

希望这不会变成一场关于devise模式的圣战 – 我想知道的仅仅是特别的**** Active Record有什么问题。

如果不好,为什么不呢?

还有什么其他问题?

有ActiveRecord的devise模式和ActiveRecord的Rails的ORM库 ,还有很多的.NET和其他语言的敲门砖。

这些都是不同的东西。 他们大多遵循这种devise模式,但是以多种方式扩展和修改它,所以在任何人说“ActiveRecord Sucks”之前,需要通过说“哪个ActiveRecord,有堆?

我只熟悉Rails的ActiveRecord,我会尝试解决使用它的所有抱怨。

@BlaM

我在Active Records看到的问题是,它总是只有一张桌子

码:

class Person belongs_to :company end people = Person.find(:all, :include => :company ) 

这会LEFT JOIN companies on companies.id = person.company_id生成与LEFT JOIN companies on companies.id = person.company_id生成的SQL,并自动生成关联的公司对象,因此您可以执行people.first.company ,因为数据已经存在,所以无需点击数据库。

@ pix0r

Active Record的固有问题是数据库查询是自动生成和执行的,以填充对象并修改数据库logging

码:

 person = Person.find_by_sql("giant complicated sql query") 

这是不好的,因为它是丑陋的,但对于你只是简单的,只需要写入原始SQL的情况下,它很容易完成。

@Tim Sullivan

…然后你select模型的几个实例,你基本上是做一个“select * from …”

码:

 people = Person.find(:all, :select=>'name, id') 

这将只从数据库中select名称和ID列,映射对象中的所有其他'属性'将只是零,除非您手动重新加载该对象,等等。

我一直发现,ActiveRecord适用于模型相对平坦的(如在,不是很多类层次的)快速的基于CRUD的应用程序。 但是,对于具有复杂OO层次结构的应用程序, DataMapper可能是更好的解决scheme。 虽然ActiveRecord假设表与数据对象之间的比例为1:1,但是这种关系在更复杂的领域中变得笨拙。 在他关于模式的书中 ,Martin Fowler指出,在你的模型相当复杂的情况下,ActiveRecord往往会崩溃,并build议使用DataMapper作为替代。

我在实践中发现这是真实的。 在您的域中有很多inheritance的情况下,将inheritance映射到RDBMS比映射关联或组合更困难。

我这样做的方式是通过您的控制器通过这些DataMapper(或“服务层”)类来访问“域”对象。 这些不直接镜像数据库,而是作为您的面向一些真实世界对象的OO表示。 假设您的域中有一个User类,并且需要引用或检索到该User对象时已经加载的其他对象的集合。 数据可能来自许多不同的表格,而ActiveRecord模式可能会使其变得非常困难。

例如,您不需要直接加载User对象并使用ActiveRecord风格的API访问数据,而是通过调用UserMapper.getUser()方法的API来获取User对象。 正是这个mapper负责从它们各自的表中加载任何关联的对象,并将完成的User“domain”对象返回给调用者。

本质上,你只是增加了一个抽象层,使代码更易于pipe理。 无论您的DataMapper类是包含原始自定义SQL,还是调用数据抽象层API,或者甚至是自己访问ActiveRecord模式,对于接收良好的,填充的User对象的控制器代码而言都无关紧要。

无论如何,这就是我如何做到的。

我认为,为什么人们对ActiveRecord感到“厌恶”,以及它的“错误”之间可能存在着截然不同的一系列原因。

在讨厌的问题上,Rails相关的东西有很多毒气。 至于什么是错误的,它可能就像所有的技术一样,在某些情况下它是一个很好的select和情况下有更好的select。 根据我的经验,您不能充分利用Rails ActiveRecord的大部分function的情况是数据库结构严重不足的地方。 如果您正在访问没有主键的数据,那么违反第一个正常forms的事情,在访问数据所需的存储过程很多的情况下,最好使用更多的仅仅是SQL包装的东西。 如果你的数据库结构比较好,ActiveRecord可以让你利用这个优势。

添加回复评论者的主题,他们用ActiveRecord中的代码片段回复

@Sam McAfee假设您的域中有一个用户类,并且需要引用或检索到该用户对象时已经加载的其他对象的集合。 数据可能来自许多不同的表格,而ActiveRecord模式可能会使其变得非常困难。

 user = User.find(id, :include => ["posts", "comments"]) first_post = user.posts.first first_comment = user.comments.first 

通过使用include选项,ActiveRecord可以覆盖默认的延迟加载行为。

我长久迟到的答案,甚至不完整,但一个很好的解释为什么我讨厌这种模式,意见,甚至一些情绪:

1)短版本:Active Record在数据库和应用程序代码之间创build一个“ 强绑定 ”的“ 薄层 ”。 它不能解决任何问题,也没有任何问题。 恕我直言,它不提供任何价值,除了程序员的一些语法糖 (然后可能使用“对象语法”来访问一些关系数据库中存在的数据)。 (IMHO …)可以更好地投入到低级别的数据库访问工具中,例如简单,简单,简单的hash_map get_record( string id_value, string table_name, string id_column_name="id" )一些变种hash_map get_record( string id_value, string table_name, string id_column_name="id" )和类似的方法(当然,这些概念和雅致因使用的语言而异)。

2)长版本:在任何我对事物的“概念控制”的数据库驱动的项目中,我避免了AR,这是好的。 我通常会build立一个分层的体系结构 (你至less在大中型项目中分层分割你的软件):

A1)数据库本身,表,关系,甚至一些逻辑,如果DBMS允许它(MySQL现在也成长)

A2)很多时候,不止一个数据存储:文件系统(数据库中的斑点并不总是一个好的决定……),遗留系统(想象一下自己“如何”访问,有多种可能……但那是不是重点…)

B)数据库访问层(在这个层次上,工具方法,帮助者很容易访问数据库中的数据是非常受欢迎的,但AR在这里没有提供任何价值,除了一些语法糖)

C)应用程序对象层:“应用程序对象”有时是数据库中表的简单行,但大多数情况下它们都是复合对象,并且附加了一些更高的逻辑,所以在这个级别上投入时间在AR对象中显然是无用的浪费了宝贵的编码器时间,因为这些对象的“真实价值”,“更高的逻辑”需要在AR对象之上实现,无论如何 – 有和没有AR! 而且,举个例子,你为什么要有一个“日志条目对象”的抽象? 应用程序的逻辑代码写入,但应该有能力更新或删除它们? 听起来很傻,而App::Log("I am a log message")le=new LogEntry(); le.time=now(); le.text="I am a log message"; le.Insert();更容易使用le=new LogEntry(); le.time=now(); le.text="I am a log message"; le.Insert(); le=new LogEntry(); le.time=now(); le.text="I am a log message"; le.Insert(); 。 例如:在你的应用程序的日志视图中使用“日志条目对象”可以工作100,1000甚至10000条日志行,但迟早你将不得不优化 – 我敢打赌,在大多数情况下,你只会在你的应用程序逻辑中使用这个漂亮的SQL SELECT语句(这完全打破了AR的想法..),而不是用僵硬的固定AR思想框架包装这个小的语句,有很多代码包装和隐藏它。 你写作和/或编写AR代码浪费的时间本来可以投入到一个更为巧妙的界面中,以读取日志条目列表(许多方法,天空是极限)。 编程人员应该敢于发明新的抽象来实现符合预期应用的应用逻辑,而不是愚蠢地重新实现愚蠢模式 ,这听起来不错!

D)应用程序逻辑 – 实现交互对象的逻辑,创build,删除和列出(!)应用程序逻辑对象(否),这些任务应该很less固定在应用程序逻辑对象本身:桌面上的纸张你的办公室所有其他表的名称和位置忘记了“静态”方法的列表对象,这是愚蠢的,一个坏的妥协,使人类的思维方式适合[一些非全AR框架 – ] AR思维)

E)用户界面 – 我将在下面写的内容非常非常主观,但以我的经验来看,构build在AR上的项目通常忽略了应用程序的UI部分 – 时间被浪费在创build模糊的抽象。 最终,这样的应用浪费了很多编码人员的时间,而且感觉就像是编码人员的应用程序,技术倾向于内部和外部。 编码员感觉很好(根据纸上的概念,终于完成了所有的工作,完成了所有的工作,并且正确无误),而且客户“只需要知道它需要这样做”,因为那是“专业的”。好吧,对不起,我离题了;-)

不过,这一切都是主观的,但是我的经验(排除了Ruby on Rails,可能会有所不同,而且我没有这种方法的实践经验)。

在付费项目中,我经常听到需要开始创build一些“活动logging”对象作为上层应用程序逻辑的构build块。 根据我的经验,这显然经常是某种理由,因为客户(大多数情况下是一个软件开发公司)没有一个好的概念,一个大的观点,对产品最终的概述。 那些客户在僵化的框架下思考(“十年前的项目中运行良好”),他们可能会充实实体,可能会定义实体关系,可能会分解数据关系并定义基本的应用逻辑,然后停止并把它交给你,并认为这就是你所需要的……他们往往缺乏一个完整的应用程序逻辑,用户界面,可用性等概念……他们缺乏大的观点,他们缺乏对细节,他们希望你遵循AR方式的事情,因为……那么为什么它在几年前就在那个项目中工作过,它让人们保持忙碌和沉默? 我不知道。 但是“细节”把男人和男人分开,或者说,原来的广告口号是怎么样的呢? 😉

经过多年(十年积极的开发经验),每当客户提到“积极的logging模式”,我的闹钟响了。 我学会了试着让他们回到那个重要的概念阶段 ,让他们三思而后行,试着展示他们的概念弱点,或者如果他们不明智,就避免他们(最终,你知道,一个还没有的客户知道自己想要什么,也许甚至认为它知道但不知道,或者试图将概念工作外在化给我免费的ME,花费我许多宝贵的时间,日子,周和月,我的时间,生活太短…)。

所以,最后:这一切都是为什么我讨厌这个愚蠢的“积极的logging模式”,我会尽可能地避免它。

编辑 :我甚至会称这是一个无模式。 它不能解决任何问题(模式并不意味着创build语法糖)。 它创造了许多问题:它的所有问题的根源(在这里的许多答案中提到)是, 它只是隐藏了由模式定义非常有限的界面背后的老的发达和强大的SQL。

这种模式取代了语法糖的灵活性!

想一想,AR解决了哪个问题?

有些消息让我感到困惑。 一些答案将“ORM”与“SQL”或类似的东西。

事实是,AR只是一个简化编程模式,您可以利用您的域对象来编写数据库访问代码。

这些对象通常具有业务属性(bean的属性)和一些行为(通常在这些属性上工作的方法)。

AR只是说“向这些域对象添加一些方法”到数据库相关的任务。

我不得不说,从我的观点和经验来看,我不喜欢这种模式。

一见钟情听起来不错。 一些像Spring Roo这样的现代Java工具使用这种模式。

对我来说,真正的问题就是面对面的问题。 AR模式强制您以某种方式将对象中的依赖项添加到基础结构对象中。 这些基础结构对象让域对象通过ARbuild议的方法来查询数据库。

我一直说两层是项目成功的关键。 服务层(商务逻辑所在的位置,或者可以通过某种远程技术(例如Web服务)导出)和领域层。 在我看来,如果我们添加一些依赖关系(不是真的需要)到领域层对象来解决AR模式,我们的领域对象将很难与其他层或(罕见的)外部应用程序共享。

AR的Spring Roo实现很有趣,因为它不依赖于对象本身,而是在一些AspectJ文件中。 但是如果以后你不想和Roo一起工作,并且需要重构项目,AR方法将直接在你的域对象中实现。

另一个angular度来看。 想象一下,我们不使用关系数据库来存储我们的对象。 想象一下,应用程序将我们的域对象存储在NoSQL数据库中,或者仅存储在XML文件中。 我们是否会实现在我们的域对象中执行这些任务的方法? 我不这么认为(例如,在XM的情况下,我们将XML相关的依赖关系添加到我们的域对象…真的很伤心,我想)。 那么为什么我们必须在域对象中实现关系数据库方法,就像Ar模式所说的那样?

总而言之,AR模式听起来更简单,更适合小型和简单的应用。 但是,当我们有复杂的大型应用程序,我认为经典的分层架构是一个更好的方法。

问题是关于Active Recorddevise模式。 不是一个orm工具。

最初的问题是用rails标记的,指的是在Ruby on Rails中构build的Twitter。 Rails中的ActiveRecord框架是Fowler的Active Recorddevise模式的实现。

我所看到的关于Active Record的投诉的主要事情是,当你围绕一个表创build一个模型,并且select模型的几个实例时,你基本上正在做一个“select * from …”。 这对于编辑logging或者显示logging来说是很好的,但是如果你想要显示数据库中所有联系人的城市列表,你可以select“从…中select城市”,只有城市。 这样做与Active Record将要求您select所有列,但只使用城市。

当然,不同的实现将以不同的方式处理。 不过,这是一个问题。

现在,你可以通过为你想要做的具体事情创build一个新的模型来解决这个问题,但是有些人会认为这比获得好处更多的努力。

我,我挖掘活动logging。 🙂

HTH

我喜欢SubSonic只做一列的方式。

 DataBaseTable.GetList(DataBaseTable.Columns.ColumnYouWant) 

, 要么:

 Query q = DataBaseTable.CreateQuery() .WHERE(DataBaseTable.Columns.ColumnToFilterOn,value); q.SelectList = DataBaseTable.Columns.ColumnYouWant; q.Load(); 

但Linq在延迟加载时仍然是国王。

@BlaM:有时候我为一个连接的结果实现了一个活动的logging。 并不总是必须是关系表< – >活动logging。 为什么不“join声明的结果”< – >活动logging?

我将要讨论Active Record作为devise模式,我还没有看到ROR。

一些开发者讨厌Active Record,因为他们阅读有关编写干净整洁的代码的聪明书,并且这些书指出活动logging违反单个resposobility原则,违反DDD规则,域对象应该是持久的愚昧,以及这些书中的许多其他规则。

Active Record中的第二个域对象往往与数据库是一一对应的,这可能被认为是某种系统(主要是n层)的限制。

那只是抽象的东西,我还没有看到Ruby on Rails实际执行这种模式。

我在Active Records看到的问题是,它总是只有一张桌子。 没关系,只要你真的只使用一张表,但是在大多数情况下使用数据的时候,你会在某个地方进行某种连接。

是的, 性能方面, 连接 通常没有连接要糟糕,但通过首先读取整个表A,然后使用获得的信息来读取和过滤表B, 连接 通常“假”连接好。

ActiveRecord的问题是,它自动为您生成的查询可能会导致性能问题。

你最终会做一些不直观的技巧来优化查询,让你想知道如果手工编写查询会更有效率。

虽然所有关于SQL优化的其他评论肯定是有效的,但是我对主动logging模式的主要抱怨是它通常会导致阻抗不匹配 。 我喜欢保持我的领域清洁,并妥善封装,活跃的logging模式通常会破坏所有的希望。

尝试做一个多对多的多态关系。 不那么容易。 特别是当你不使用STI。