3

我正在开始一个新项目，我最近发现了城堡项目 activerecord，这似乎是一个很棒的解决方案，但同时，它看起来确实非常规。我想知道，这种感觉是来自于学习新东西（我应该习惯它）还是真的很糟糕？

4

7 回答 7

5

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

但事实证明你不必！而不是拥有，说：

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

你可以有

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

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

于 2009-05-21T03:15:42.683 回答
3

ActiveRecord是由 Martin Fowler 在企业应用程序架构模式中首次命名的设计模式。它相当普遍，并在流行的 Ruby 框架 Rails 中广泛使用。

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

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

于 2009-02-04T11:00:56.783 回答
3

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

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

于 2009-02-04T11:12:41.860 回答
0

ActiveRecord 在 Ruby 中工作得很好，但它不容易转移到所有语言。AR 的核心壮举是table=class, row=instance的隐喻。这在 Ruby 中非常优雅，因为类也是对象。在其他语言中，类通常是一种特殊的构造，然后您必须经历各种麻烦才能使其正常工作。这带走了它在 Ruby 中的一些自然感觉。

于 2009-02-04T11:17:37.387 回答
0

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

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

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

于 2009-02-04T11:19:57.040 回答
0

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

User.Service.Save(user);

如果您使用的是 .NET，那么 ActiveRecord 显然是基于 ActiveRecord、Coolstorage、Subsonic 和其他一些。

于 2009-02-04T11:21:41.297 回答
0

我认为 ActiveRecord 与 Castle 关系不大，因此，这个问题的答案ActiveRecord 模式是否遵循/鼓励 SOLID 设计原则？可能对许多人更有启发性。

于 2013-09-05T00:53:56.430 回答