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 -- Posted via http://www.ruby-forum.com/.
>>>>> "Stewart" == Stewart Matheson <smathe2@hotmail.com> 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 Dybedahl <calle@cyberpomo.com> http://www.livejournal.com/users/cdybedahl/ "Then I dream of a world where idiots are hunted like wild pigs" -- Stephen Edwards, scary.devil.monastery
http://www.pragmaticprogrammer.com/titles/rails/index.html -- -- Tom Mornini On Mar 26, 2006, at 3:59 AM, Stewart Matheson wrote:> 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 > > -- > Posted via http://www.ruby-forum.com/. > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails
http://karmacrash.com/pages/readingonrails -------------- next part -------------- An HTML attachment was scrubbed... URL: http://wrath.rubyonrails.org/pipermail/rails/attachments/20060326/677f8fa1/attachment.html
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
Stewart Matheson wrote:> 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
>
Tim Case 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> > > ------------------------------------------------------------------------ > > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails
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 Case tim@karmacrash.com On 3/26/06, Ben Munat <bent@munat.com> wrote:> > Tim Case 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 > > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > Rails mailing list > > Rails@lists.rubyonrails.org > > http://lists.rubyonrails.org/mailman/listinfo/rails > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails >-------------- next part -------------- An HTML attachment was scrubbed... URL: http://wrath.rubyonrails.org/pipermail/rails/attachments/20060326/533313c6/attachment.html
Tim Case 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.> 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.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...> 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.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> Cheers, > > Tim Case > tim@karmacrash.com <mailto:tim@karmacrash.com> > > > > On 3/26/06, *Ben Munat* < bent@munat.com <mailto:bent@munat.com>> wrote: > > Tim Case 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 > > > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > Rails mailing list > > Rails@lists.rubyonrails.org <mailto:Rails@lists.rubyonrails.org> > > http://lists.rubyonrails.org/mailman/listinfo/rails > <http://lists.rubyonrails.org/mailman/listinfo/rails> > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org <mailto:Rails@lists.rubyonrails.org> > http://lists.rubyonrails.org/mailman/listinfo/rails > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails