|
|
|
|
|
by halostatue
4488 days ago
|
|
Here's the thing, though: Rails purposefully doesn't provide more than the minimum. I disagree with DHH on many things (ActiveRecord’s persistence model being based on MySQL misfeatures has been one of my biggest frustrations with Rails since he introduced it at a RubyConf where we both presented), but he's right that this sort of thing doesn't belong in Rails. Everyone[1] needs a persistence layer and domain objects. That ActiveRecord is both ActiveModel and persistence is neither here nor there—and Rails 3 did a lot to making it possible to separate ActiveModel (domain object behaviour) and ActiveRecord (persistence layer behaviour) in a logical perspective so you can choose to persist differently than ActiveRecord does. Everyone needs some kind of controller. Everyone needs some kind of presentation layer. Aside from providing sane defaults for all of this, Rails doesn't try to dictate how your application is built. The “more complex” architecture required for your application is unlikely to be a good fit for my application’s “more complex” architecture. For Rails to anoint one particular “more complex” architecture…is to fail anyone else who doesn’t need that architecture or would need something different. If you want to promote a particular type of architecture, there are ways: write an Engine; include generators. Give people guidance. Tell people why they want to use your particular architecture, but also tell them why they shouldn’t use it. If a lot of people need it, they will adopt it. Like Rspec. Like cucumber. Like ActiveModel::Serializers. And, honestly, consider whether you really need your “more complex“ architecture or whether you can combat it the same way that Basecamp does. We're doing that with our product team, trying to find features we can remove and reimplement later when we really need them. Ours is a fairly mature product, so it's hard—but it's happening. [1] For some large subset of everyone. Anyone who is reaching for something like Rails, Django, etc. needs some sort of persistence layer. Anyone who needs to store data needs that. Everyone needs domain objects. |
|