Yeah. Exactly. The way I see this, the only function of the service layer is to wrap calls to Transfer... which, frankly, is a bit redundant for most applications.
Then again, I'm still giving this a lot of thought. "Real" OOP has caught my attention lately mostly due to Joe Rinehart's ORM posts and Hal Helms's responses... it's gotten me thinking about Hal's objection to Transfer as a DB-centric device that's anathema to "really good OO domain models". I also have no real training in programming, so I tend to make a lot of this stuff up as I go. So take this all for what it is (and what it's worth): My own (probably uninformed) take on what I see as valuable in application architecture. I'll be the first to admit that a lot my observations over the last 2 years have met with some strong resistance from friends and colleagues, so it's hard to know if I'm being less a follower of entrenched thinking than they are or if I'm so far off base that I should be locked in a padded cell and the key ground to powder. ;) So yeah, maybe I've a screw loose... it's happened before, but I am thinking that if Transfer is acting as both the object factory for business objects and the persistence API it sort of makes a more traditional service/persistence mechanism, well, redundant. If the controller is doing nothing but pulling values from the event and dumping them into the service layer and then pulling data from the service layer and pushing them to the view, where's the value in having service classes and DAO and/or Gateway classes? I guess what I'm thinking is that if you have all the behavoirs the application needs encapsulated within the domain objects and the those objects are all served up and persisted by Transfer, what value is a separate service layer and CRUD layer? This has far less to do with OOP than it does stable application architecture. I know even Mark uses the DAO/Gw pattern and the Manager pattern (albeit referred to as Services), but I'm starting to wonder if that's the right direction. I have to read some more and talk about this with some folks. Thoughts? J On Nov 19, 2008, at 12:39 PM, Bob Silverberg wrote: > > So you'd have your controller talking directly to Transfer? Is > that the idea? > > On Wed, Nov 19, 2008 at 1:26 PM, Jared Rypka-Hauer > <[EMAIL PROTECTED]> wrote: >> >> It depends on how you look at it, if ORM is object --> relational, >> then it's no misuse at all, you're using Transfer as an object >> factory to get your business objects and if they happen to have >> persistence integration well that's cool. ... --~--~---------~--~----~------------~-------~--~----~ Before posting questions to the group please read: http://groups.google.com/group/transfer-dev/web/how-to-ask-support-questions-on-transfer You received this message because you are subscribed to the Google Groups "transfer-dev" group. To post to this group, send email to transfer-dev@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/transfer-dev?hl=en -~----------~----~----~----~------~----~------~--~---
