Question

我正在开始一个新项目，我最近发现了城堡项目的主动记录，这似乎是一个很好的解决方案，但与此同时，它看起来像一些非常规的东西。我想知道，这种感觉是来自于学习新东西（我应该习惯它）还是非常糟糕的做法？

Answer 1

使用ActiveRecord让我觉得奇怪的部分原因是必须继承ActiveRecordBase<T>，并在对象上使用所有这些持久性方法（Save等等。）

但事实证明你没必要！而不是说：

[ActiveRecord]
class Customer : ActiveRecordBase<Customer> { }

你可以拥有

[ActiveRecord]
class Customer : inherit from whatever you want { }

然后使用ActiveRecordMediator<Customer>。它与ActiveRecordBase<T>具有基本相同的静态方法，但这样您就不必使用它们来混淆对象模型。如果您不需要ActiveRecordBase<T>中的各种受保护方法事件挂钩，这可以使事情变得更简单。

Answer 2

ActiveRecord是由Martin Fowler在企业应用程序架构模式中首先命名的设计模式。它在流行的Ruby框架Rails中非常常见并广泛使用。

与.Net世界中使用DAO的更常见的开发风格形成鲜明对比，这或许可以解释为什么你会感到不安。

建议：阅读一些与您自己的项目类似的Ruby on Rails应用程序的源代码，并评估您喜欢大量使用ActiveRecord所导致的设计风格。

Answer 3

这不是一个糟糕的解决方案，但它有它的缺点。

在企业应用程序体系结构模式中Martin Fowler介绍了几种设计基于数据库构建的应用程序的方法。这些方法在应用程序与数据库分离的方式上有所不同。他还描述了更多的解耦使得更复杂的应用成为可能。 Active Record被描述为一种设计更简单应用程序的方法，但对于行为更复杂的应用程序，您需要一个独立于数据库的域模型，以及介于两者之间的对象关系映射器。

Answer 4

ActiveRecord在Ruby中运行良好，但它不容易转移到所有语言。 AR的核心壮举是 table = class，row = instance 的隐喻。这在Ruby中非常优雅，因为类也是对象。在其他语言中，类通常是一种特殊的构造，然后你必须经历各种各样的箍以使其正常工作。这消除了它在Ruby中的一些自然感觉。

Answer 5

不，这不是坏习惯。即使在.NET中，它现在也是一个相当完善的模式。 SubSonic（http://subsonicproject.com）和LINQ to SQL也使用该模式。

模式的实现，例如Subsonic，非常适合快速轻松地创建管理应用程序CRUD的数据访问层。

这并不意味着它对所有系统都是一个很好的解决方案。对于大型复杂系统，您可能希望与数据存储的耦合较少。

Answer 6

域对象与服务层的混合是最大的不良做法（如果你认为这是一种不好的做法）。你最终调用user.Save（），这意味着如果你想改变你的ORM，你依赖于这种模式。 2个替代方案是一个层，也就是一组外观类，用于执行CRUD操作，或者将其放在域对象中，如

User.Service.Save(user);

如果你使用.NET，那么ActiveRecord显然是基于ActiveRecord，Coolstorage，Subsonic和few others。

Answer 7

我认为ActiveRecord与Castle没什么关系，因此，这个问题Does the ActiveRecord pattern follow/encourage the SOLID design principles?的答案对许多人来说可能更具启发性。

ActiveRecord是不好的做法？

7 个答案: