Datamapper. Blog: http://random8.zenunit.com/ Learn rails: http://sensei.zenunit.com/
On 04/02/2009, at 1:59 PM, sbrocher <sbroc...@gmail.com> wrote: > > Hi, > > I've implemented a few big RoR apps. I do have some good experience > building large systems in many different languages and platforms but I > don't consider myself a RoR guru, so I'd like you experts comment on > my thoughts. > > I'd like to divide a large system (app) into several functional, high- > level sub-systems. These are higher level than rails Models, and > provide APIs that implement business logic around functional groups. > Examples of these are billing manager, security manager (accounts, > privileges, roles, etc), inventory manager, manufacturing manager, and > such (of course, these are just examples, but you get the point). > > These high-level sub-systems may be implemented as servers (think > SOAP / REST / XML-RPC / ...), or just plain Ruby classes. Some of > these sub-systems implement integrations with other systems, for > example, a credit card gateway, an accounting system, Fedex, you name > it. Some of the sub-systems may be just proxies to a system > implemented on some other technology. > > The user interface (views) would not have access to any of the Models. > They just present and / or grab data that is prepared for them / > pushed back to the controllers as local variables / arrays / hash > tables that don't reflect an actual Model. > > The controllers do not have access to Models either. Instead, they > call methods from the high-level functional sub-system APIs. > > The Models implement lower-level business logic related to how to the > information is stored and retrieved from the database, the pertinent > validations, associations, etc. but do not implement high-level > business logic such as "how do I bill Joe for a specific event that > results in the combination of many other parameters and variables that > at the end come from diverse fields on many different tables on the > underlying database structure". > > The high-level sub-systems all share the same database and therefore > same data model and only communicate with each other via their APIs, > and can access all Models directly. > > In other words, this would work more or less as a new layer in between > the MVC pattern: > > view <-> controller <-> high-level sub-system <-> models <-> database > > The idea is to build the app in a more robust / less coupled way where > I can exchange parts of the app by different technologies and other > applications in the future without having to recode a bunch of things. > For example, the security subsystem could one day be replaced by an > AAA server and then the subsystem would be re-implemented to call the > AAA server (to replace its own original implementation), however the > rest of the app would continue to use the same API calls to the > security subsystem and so the change is isolated from the rest of the > app. > > The problem with this is, I'd loose many of the RoR goodness, such as > form helpers, easy models validation thrown back to the interface, > etc. > > Am I missing some Ruby language construct or RoR framework construct > that would enable me to implement this kind of design on an easier > manner? Should I instead be thinking of many RoR applications somehow > talking to each other? > > I really like RoR but I'm starting to find myself on a tough situation > dealing with evolving mid-to-large systems (think 50+ database tables > and 8+ sub-systems). I need to come up with a pattern that would force > me to implement and design code that works and is maintainable on a > long-term vision, however I'm not sure if this is because I don't know > the 100% of what the language and framework has to offer, or if I am > just using it the wrong way (or both? :-). > > Comments? > > Thanks, > Seb > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk@googlegroups.com To unsubscribe from this group, send email to rubyonrails-talk+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
