我正在开始一个新项目,我最近发现了城堡项目的主动记录,这似乎是一个很好的解决方案,但与此同时,它看起来像一些非常规的东西。 我想知道,这种感觉是来自于学习新东西(我应该习惯它)还是非常糟糕的做法?
答案 0 :(得分:5)
使用ActiveRecord让我觉得奇怪的部分原因是必须继承ActiveRecordBase<T>
,并在对象上使用所有这些持久性方法(Save
等等。)
但事实证明你没必要!而不是说:
[ActiveRecord]
class Customer : ActiveRecordBase<Customer> { }
你可以拥有
[ActiveRecord]
class Customer : inherit from whatever you want { }
然后使用ActiveRecordMediator<Customer>
。它与ActiveRecordBase<T>
具有基本相同的静态方法,但这样您就不必使用它们来混淆对象模型。如果您不需要ActiveRecordBase<T>
中的各种受保护方法事件挂钩,这可以使事情变得更简单。
答案 1 :(得分:4)
ActiveRecord是由Martin Fowler在企业应用程序架构模式中首先命名的设计模式。它在流行的Ruby框架Rails中非常常见并广泛使用。
与.Net世界中使用DAO的更常见的开发风格形成鲜明对比,这或许可以解释为什么你会感到不安。
建议:阅读一些与您自己的项目类似的Ruby on Rails应用程序的源代码,并评估您喜欢大量使用ActiveRecord所导致的设计风格。
答案 2 :(得分:3)
这不是一个糟糕的解决方案,但它有它的缺点。
在企业应用程序体系结构模式中Martin Fowler介绍了几种设计基于数据库构建的应用程序的方法。这些方法在应用程序与数据库分离的方式上有所不同。他还描述了更多的解耦使得更复杂的应用成为可能。 Active Record被描述为一种设计更简单应用程序的方法,但对于行为更复杂的应用程序,您需要一个独立于数据库的域模型,以及介于两者之间的对象关系映射器。
答案 3 :(得分:0)
ActiveRecord在Ruby中运行良好,但它不容易转移到所有语言。 AR的核心壮举是 table = class,row = instance 的隐喻。这在Ruby中非常优雅,因为类也是对象。在其他语言中,类通常是一种特殊的构造,然后你必须经历各种各样的箍以使其正常工作。这消除了它在Ruby中的一些自然感觉。
答案 4 :(得分:0)
不,这不是坏习惯。即使在.NET中,它现在也是一个相当完善的模式。 SubSonic(http://subsonicproject.com)和LINQ to SQL也使用该模式。
模式的实现,例如Subsonic,非常适合快速轻松地创建管理应用程序CRUD的数据访问层。
这并不意味着它对所有系统都是一个很好的解决方案。对于大型复杂系统,您可能希望与数据存储的耦合较少。
答案 5 :(得分:0)
域对象与服务层的混合是最大的不良做法(如果你认为这是一种不好的做法)。你最终调用user.Save(),这意味着如果你想改变你的ORM,你依赖于这种模式。 2个替代方案是一个层,也就是一组外观类,用于执行CRUD操作,或者将其放在域对象中,如
User.Service.Save(user);
如果你使用.NET,那么ActiveRecord显然是基于ActiveRecord,Coolstorage,Subsonic和few others。
答案 6 :(得分:0)
我认为ActiveRecord与Castle没什么关系,因此,这个问题Does the ActiveRecord pattern follow/encourage the SOLID design principles?的答案对许多人来说可能更具启发性。