Hello I have been using LAMP for the last 6 years and i am now finally
making the choice to move over to RoR. This MVC stuff is all very new to
me. As i have no trouble understanding ruby code… or any code for that
matter… my challange comes in getting my head around the MVC stuff. Is
there any demos articles that you guys have seen that takes a site or a
business breif and explains where to use controllers where to use models
and where to use views… An over all idea of MVC desgin is what i am
after. I have already looked on the rails wiki and found that its a
little berif… any suggestions
“Stewart” == Stewart M. [email protected] writes:
Hello I have been using LAMP for the last 6 years and i am now
finally making the choice to move over to RoR. This MVC stuff is all
very new to me. As i have no trouble understanding ruby code… or
any code for that matter… my challange comes in getting my head
around the MVC stuff.
The MVC pattern is not specific to RoR. In fact, it’s a good deal
older than either Ruby or Rails, since it was first described back in
1979. Any good book on program architecture should talk about it. This
Wikipedia article may be a good start:
Model–view–controller - Wikipedia
Calle D. <[email protected]>
http://www.livejournal.com/users/cdybedahl/
"Then I dream of a world where idiots are hunted like wild pigs"
-- Stephen Edwards, scary.devil.monastery
Tim C. wrote:
Nicely done… this is a good reference for new (and maybe some
not-so-new) Rails developers.
However, as a raging DDD fanboy, I have to take issue with your coverage
of that… a
little…
Ubiquitous Language is supposed to be more about the names and behaviors
of entities in
the system, rather than framework-specific helper methods. Not to
belittle the rails
relationship facilities… they’re great. But I think Evans was more
interested in the
names we use to build our model and making sure that they’re the same
names that the
stakeholders use. My favorite part of that: developers should be able to
speak out loud
the actions of the various entities in the system and the stakeholders
should just get it.
If not, you haven’t captured the real model.
I’d also say that, other than enforcing good MVC habits, rails does
absolutely nothing to
encourage good domain-driven design. The fact that model objects descend
from ActiveRecord
both interferes with the natural course of creating entity hierarchies
and causes
confusion as to whether it’s okay to have a model object that’s not an
AR subclass.
Persistence is an orthogonal concern (I don’t think Evans even discusses
it) and should be
as trasparent as possible to the model. The fact that rails encourages
designing your
domain by creating db DDLs would probably give Evans a heart-attack (it
gives me
heartburn, that’s for sure).
I think there’s room here for rails to find yet another
“duh-why-didn’t-we-think-of-that”
piece of convenience: create modules (the ruby kind) for certain domain
stereotypes
(aggregate root, repository, etc.). Perhaps that could even be tied into
a generator. And,
following the good domain-specific-language tendencies that rails has
embraced, these
sterotypes could be expressed as declaration/method calls on the class
in question (like
the relationship stuff)… like:
class Project < AR::Base # though we really need to figure out how
to mixin AR
aggregate_root :client, :project_manager, :some_other_project_child
belongs_to …
has_many …
end
Well, that’s just off the top of my head, but…
Anyway, it’s still great to see people talking about DDD. I think that
book – published
two years ago - will hit its stride in another couple years.
b
Hi Thanks, I appreciate your kind words about ReadingonRails and your
thoughts about DDD. However short Rails might come up in directly
encouraging (and I’m not willing to concede it does) it, DDD is
definitely
an influence on Rails if only by virtue of the fact that I asked DHH
directly if it was or not and he enthusiastically confirmed that it was.
A couple of issues with your issues:
-
One aspect that seems to get lost by many people with Rails is that
you
are not at all required to tie your model objects to ActiveRecord, it’s
perfectly fine and encouraged to design your models as best as possible
to
fit the domain you are modeling and if that means separating from
ActiveRecord then, go for it. ActiveRecord is a strategy for ORM not
domain
modeling. -
Consider how much in line Rails is with Ubiquitous language when a
developer can say to a stakeholder “A person has many contacts and a
contact
has many addresses.”, I think you can “speak this out loud” and stand a
good
chance that the stakeholder will just get it. It’s nothing to sneeze
over
when you consider how these relationships are codified in other
environments. -
And finally, I have to pull the trump card that is Ruby and say that
a
tremendous about work is being done right now inside and outside of
Rails
towards Domain Specific Language, that take the concept of language in
code
and speech and bring it closer to bridging the gap between the two, and
while Rails may not be the perfect implementation of Evan’s entities
there
is nothing to prevent someone from enacting his ideas through Ruby (and
Rails) in much the way you described below.
Domain Driven Design was the influence on Rails that I saw the most
potential for in much the same way you described that it might hit it’s
stride in a couple of years. It’s definitely on the mind of quite a few
present in this community and I think the kinds of domain modelling
people
represent in Rails will become more complex as the framework matures.
This
is still just the beginning…
Cheers,
Tim C.
[email protected]
http://www.c2.com/cgi/wiki?ModelViewController
It’s just a design pattern… if you don’t know the significance of
that, you should read
up on them too:
http://www.c2.com/cgi/wiki?DesignPatterns
http://www.patterndepot.com/put/8/JavaPatterns.htm
(entire book online… even if it uses java…)
http://www.google.com/search?q=design+patterns
To me, the two most important benefits of MVC and design patterns in
general are a)
flexibility of design (“future-proofing”) and b) a common
language/structure to facilitate
understanding. You can take your MVC knowledge and work on any MVC
system.
The downside of MVC is more code… using MVC to serve a simple site
with a handful of
pages is probably overkill (though I actually wouldn’t say that
anymore… with Rails).
The tricky part is knowing when your past the “serving a few pages with
some php in 'em”
and into the “we need architecture”.
The very nice thing about Rails is it makes working with MVC trivial…
it does most of
the legwork for you. It also means that there’s a common application
architecture right
off the bat. I’ve had all sorts of arguments about how to structure java
apps…
The most important thing to remember is that it’s never as complicated
as it sounds. 
b
Tim C. wrote:
Hi Thanks, I appreciate your kind words about ReadingonRails and your
thoughts about DDD. However short Rails might come up in directly
encouraging (and I’m not willing to concede it does) it, DDD is
definitely an influence on Rails if only by virtue of the fact that I
asked DHH directly if it was or not and he enthusiastically confirmed
that it was.
Well, that’s great to hear… unfortunately I don’t think he got it
quite right.
ActiveRecord should be a mixin. Period. It would also be more ideal if
Rails allowed
transaparent swapping of persistent services.
A couple of issues with your issues:
- One aspect that seems to get lost by many people with Rails is that
you are not at all required to tie your model objects to ActiveRecord,
it’s perfectly fine and encouraged to design your models as best as
possible to fit the domain you are modeling and if that means separating
from ActiveRecord then, go for it. ActiveRecord is a strategy for ORM
not domain modeling.
Yes, persistence is a cross-cutting, orthagonal concern not pertinent to
domain-modeling… so why do we pollute our inheritance hierarchy with
non-domain
concepts? I’m sorry but extending a persistence base class just seems
naive… like a
beginners OOP tutorial.
- Consider how much in line Rails is with Ubiquitous language when a
developer can say to a stakeholder “A person has many contacts and a
contact has many addresses.”, I think you can “speak this out loud” and
stand a good chance that the stakeholder will just get it. It’s nothing
to sneeze over when you consider how these relationships are codified in
other environments.
I agree that the relationship issues are a plus and help code
readability but I don’t
think that’s what Evans had in mind. On the other hand, he had never
seen rails, so…
- And finally, I have to pull the trump card that is Ruby and say that
a tremendous about work is being done right now inside and outside of
Rails towards Domain Specific Language, that take the concept of
language in code and speech and bring it closer to bridging the gap
between the two, and while Rails may not be the perfect implementation
of Evan’s entities there is nothing to prevent someone from enacting his
ideas through Ruby (and Rails) in much the way you described below.
Not sure if it’s a “trump card” when I completely agree with you. 
Part of what
attracted me to ruby was the ability to create DSLs with a lot less fuss
than Java.
Ideally, I like to see business rules that are written out as english
sentences. If these
are also executable, that seems like an ideal situation.
Domain Driven Design was the influence on Rails that I saw the most
potential for in much the same way you described that it might hit it’s
stride in a couple of years. It’s definitely on the mind of quite a few
present in this community and I think the kinds of domain modelling
people represent in Rails will become more complex as the framework
matures. This is still just the beginning…
I hope so!
b