nas*_*nas 7 ruby oop activerecord ruby-on-rails
我已经使用Rails超过4年了,所以很明显我喜欢Rails并喜欢Rails Way的做法,有时我会在不知不觉中陷入黑暗的一面.
我最近选择了鲍勃叔叔的清洁代码.我在第6章,有点困惑我们是否作为铁轨开发人员打破了OO设计的基本规则,即Demeter法则或封装？Demeter法则指出一个对象不应该知道另一个对象的内部,它不应该调用方法返回的对象上的方法,因为当你这样做时,它会建议一个对象对另一个对象有太多的了解.
但是我们经常从模型中调用另一个对象的方法.例如,当我们有一个像'一个订单属于一个用户'的关系时.然后我们经常最后做order.user.name或者为了防止它看起来像火车残骸,我们设置了一个委托来做order.name.
这还不像打破得墨忒耳法或封装法吗？
另一个问题是:ActiveRecord只是一个与数据库接口的数据结构或数据传输对象吗？
如果是,那么我们不是通过将我们的业务规则放在ActiveRecord模型中来创建混合结构,即半对象和半数据结构吗？
小智 15
Rails是Rails.还有什么可说的.是的,Rails中的一些习语违反了良好的设计原则.但是我们容忍这个,因为它是Rails的方式.
话虽如此,在大多数rails应用程序中使用的模型太多了.我经常看到直接访问模型的视图代码.我将业务规则折叠到活动记录对象中.更好的方法是将业务规则与活动记录隔离开来,并将视图与模型隔离开来.这不会违反任何rails惯用语,并且会使rails应用程序更加灵活和可维护.
恕我直言,如果你过分遵循纯粹的方法,那么你最终会像Java一样混乱,它会使用所有正确的设计模式,但没有人能够记住打开文件并阅读其内容所需的八行代码.
Rails的ActiveRecord框架是Martin Fowler的Active Record设计模式的实现.Rails中的Active Records当然不仅仅是愚蠢的数据结构或DTO,因为它们具有行为:它们执行验证,它们可以告诉您它们的属性是否已经改变等等,并且您是自由的,并且确实受到鼓励,在那里添加您自己的业务逻辑.
Rails通常鼓励良好的做法,例如MVC和句法醋,使坏事和/或丑陋.
| 归档时间： |
|
| 查看次数： |
1331 次 |
| 最近记录： |