Hello Seb, An approach that I have used is to place the higher level business logic in model objects that do not inherit from ActiveRecord. In the way I think about larger systems, the higher level business logic is still part of the model. The model is not limited to managing the persistence of state. I don't have a formal way of organizing these subsystem model objects as I haven't tackled any projects that sound as extensive as what you are working on.
HTH Kim On Feb 4, 2009, at 11:28 AM, sbrocher wrote: > > 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 - > > > -- Kim Shrier - principal, Shrier and Deihl - mailto:k...@tinker.com Remote Unix Network Admin, Security, Internet Software Development Tinker Internet Services - Superior FreeBSD-based Web Hosting http://www.tinker.com/ --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
