MVC Design


#1

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


#2

http://www.pragmaticprogrammer.com/titles/rails/index.html


– Tom M.


#3

“Stewart” == Stewart M. removed_email_address@domain.invalid 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:
http://en.wikipedia.org/wiki/Model_view_controller

	     Calle D. <removed_email_address@domain.invalid>
	 http://www.livejournal.com/users/cdybedahl/
   "Then I dream of a world where idiots are hunted like wild pigs"
	  -- Stephen Edwards, scary.devil.monastery

#4

http://karmacrash.com/pages/readingonrails


#5

Tim C. wrote:

http://karmacrash.com/pages/readingonrails

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


#6

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:

  1. 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.

  2. 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.

  3. 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.
removed_email_address@domain.invalid


#7

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. :slight_smile:

b


#8

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:

  1. 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.

  1. 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…

  1. 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. :slight_smile:
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