Hi Julian, Thanks for your answer. I've seen Datamapper before. However, the way I understand it, Datamapper is pretty much just a replacement for ActiveRecord, so I don't see how it would add the extra layer of abstraction I'm searching for... Did I miss something here?
Thanks Seb On Feb 3, 9:33 pm, Julian Leviston <jul...@coretech.net.au> wrote: > 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- Hide quoted text - > > - Show quoted text - --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
