How Many Classes Per Business Object?

Your timing is impeccable. Our company is moving more towards more OO development with ColdFusion and we're trying to find the best way of doing so. Right now, we're doing everything in one CFC, but it sounds like the implementation you propose is a smarter way to go. Wondering if you might be willing to share an example of an Object, ObjectService, and ObjectDAO. Thanks! Ryan

I generally agree with Brian: suppose you have an e-commerce app, you'll generally have an orderBean, an orderDAO, an itemBean, an itemDAO and finally one service on which you can manage, may be in a transaction, order and items.
however, this is a service oriented approach: in a pure oo approach you have to encapsulate properties and methods in one single class, so in this case you'd have one class for the order example.
regards
salvatore fusto

I'm with Brian and Phill. Perhaps this is because I'm using transfer more and more, but it just feels right to define a Service by business unit. BillingService to provide an API for Orders, Invoices, PaymentTerms, etc. Or a CatalogService for Categories, Products, Bundles, etc.

@Andy I get you're frustration, but be wary of using one object for everything. You risk the "god object" phenomenon and are likely coupling code that will cause problems if you need to change something down the road. If your co-workers uses UML, have him draw out the object composition for the classes he creates. It will be much easier to understand the path of delegated method calls. As an added bonus, you'll get a visually documented API.

@Ryan: If you haven't seen it yet, I've been posting an OO with CF primer on my site.

http://www.iknowkungfoo.com/blog/index.cfm/2007/8/...

I'll be posting about Service and Factory objects soon.

@Andy: I understand your frustrations, but once you get into using OO concepts on a regular basis, you should start to see why using multiple objects with small amounts of code to handle certain processes can be a good thing. Of course, you can go overboard with anything, KISS applies to OOP as well.

@ Ryan, My example code would be very use case specific, but I'll try to post more on my sample API!

@Phil, Definitely no "one true way" (well, except MY way, of course :->). In your specific case I just have a User.authenticate() which may just ask the user what groups is has using ORM, so I dont need to write the code. Agree you could add a SecurityService, but I'm just going for the simplest thing that can work!

@Salvatore, But through ORM your Order has Items, so while I have an API by default for accessing items, I'll just go to the Order service to get the order loaded - including its associated items.

@Andy, Until that CFC is 12,000 lines long and then it is a pain. Also, because there are no such thing as class methods in CF (unlike Ruby, Smalltalk and even Java) you're probably going to NEED to have both a business object and some place to stick the code that relates to collections of such objects (which I break up between the Service class and a DAO for database access). It's frustrating to learn, but works really well when you get into the flow.

@Paul, I'm still trying to get the methods that a BillingService would have that I couldn't just call drectly on the Order, Invoice, PaymentTerms given defined relationships between them. Not saying they don't exist - just need the right example to get me over the hump!

@Matt, I think number of objects is a goldilocks problem. Too many files is too much jumping in and out of different items. Too few leaves you with too much scrolling and more file update collisions in a collaborative environment. The answer is to have "not too many, not too few" files, but because it doesn't really matter if you have a few more or a few less, I think the goldilocks point varies between developers, driving some of the disagreement we see on lists.

BTW, Andy's been trying to reply to everyone, but all of his posts seem to be getting deleted. He clicks "Add Comment", fills out the form, but when he clicks submit it just disappears and the blog page refreshes without adding his comments.

You know what I think...I think some developers use procedural code just so that they can say they are the true keepers of the simplicity of CF and can blast the rest of us for making things too complicated. This does nothing but leave a mess of procedural spaghetti code for the rest of us to clean up when the application needs to be maintained. All for what? For procedural/spaghetti bragging rights?

Sound ridiculous? Of course, but no less ridiculous than the opposite. I am seriously tired of the anti-OO crowd hijacking decent conversations. Don't want to use OO? Don't (just please don't ask me to maintain your uber-user.cfc)...but what compels you to join in a conversation that doesn't apparently interest or concern you? What so different than those comments and your typical blog troll? I am sorry as I am not meaning to insult anyone, its just this conversation is old and silly and pointless and actually has nothing to do with the question Peter asked IMO.

Anyway, back on topic... Peter, what is wrong with Paul's example? Seems like a perfectly valid example to me.

Hi Brian,

Good question! Firstly, Pauls example is perfectly valid, and I quite like it as an example. There is nothing I could or would want to say against that approach. Here is my situation. I want to build applications as quickly as possible, generating as much of them as possible while still consistent with them being well architected and maintainable. I am currently doing quite well by generating one service class per business object (actually I only create the physical service classes for business objects that have custom service class code which is usually maybe a third of them - the rest I just instantiate the base class which keeps my directories nice and tidy).

What I like about the 1:1 approach is that I have a DSL for describing business objects. You describe the table name and the title, what editing methods are allowed, you describe all of the properties (including calculated and associated properties) and their rich data types so I can gen all the admin code. You describe their validations, transformations and their relationships to other objects and you declaritively describe any class methods that don't need to be hand coded (anything that could be done as a parameterized call - stuff like deleteExpiredCarts() or getAdminUsers() or the like).

You put that XML info a config directly, boot up the app and it automatically gives you a working application with rich admin features, versioning, rollback, all kinds of other goodness. To date I have not run into any problems with this approach, but I am concerned as there are two reasons why you don't run into a problem. One is because there isn't one, and the other is because it's just around the bend you're taking at 90mph and you just don't know you are heading for a train wreck!!!

What I'm trying to identify is whether my simpler approach is heading for a train wreck. What I'm looking for is an example of something that just plain wouldn't work with my current approach or that makes it look really unwieldy to work with. If I see such an example, I can either decide it's outside of my use case, change the way I do everything, or provide a new extension point to deal with such cases. So what I'm really trying to find is a case where my current approach will really suck as opposed to examples where other approaches would also work (which is more what Pauls example feels like to me).

None of that is to say my approach is better than what Paul suggested. I'm just looking for cases where what I'm doing is clearly worse!

Make sense?

Peter,

For me the cases for a multi-object service layer are where you have:

a) a non-OO client
b) an OO client that can't consume your objects natively, or
c) a remote client where you want to minimize trips to the server

If writing public web services, I'd assume I have to cater for at least a and b, and probably c is a concern as well.

However, if you can bring the domain model into the client process and there's no reasonable prospect that you might have to go multi-tier, I'm with you, just use the fine-grained API inherent in the domain objects.

Jaime

I don't see it as "clearly worse" at all...just a matter of personal preference is all.

I just got done with my Design Patterns and ColdFusion preso to the CFMeetup group and this issue came up in Q & A (and in fact someone posted your blog entry link to chat - after we stopped recording the session).

As I explained in that chat session, I tend to have a bean per noun and those will be as smart as necessary to model the noun but my data gateways will handle groups of related beans. E.g., in the e-commerce example, invoices, orders and items etc are all closely related so I'd probably have an InvoiceGateway that handled persistence for all three. I don't use separate DAOs, mostly because I use an ORM to handle that sort of SQL for me. Then my services are aligned with workflows - and may not directly match even a specific gateway, e.g., an OrderService for managing the ordering workflow that deals with user, invoice, cart, order, item objects etc. Then my controllers align with the UI concepts, e.g., CartController, ProductCatalogController.

However, the rules of thumb I use to arrive at that organization are hard to articulate so it's very difficult to provide guidelines that would help others reach the same place. Really only experience can determine how you make some of these choices.

I sympathize with Andy and Eric because the "5:1 Syndrome" (bean + dao + gateway + service + controller for everything) makes OO look much, much harder than it needs to be. Not that OO is easy - modeling your domain well is hard and something that takes lots of experience, just as good programming in general takes lots of experience. CF is both simple *and* powerful and it allows for a very wide range of programming styles (much as C++ was described by its creator, Bjarne Stroustrup, as a multi-paradigm language). If you're familiar with OO and tend to think in objects, an OO design is going to be easier and more natural than a procedural design. If you don't know OO well enough, a procedural design is going to seem easier.

1. ORM calls always go in the data gateways (except where I expose a save() method on a bean in which case the service layer may ask the bean to save itself). Transfer ORM is injected into the data gateways only, nowhere else (well, my afterNew event listener knows about Transfer so it can inject it into decorated beans of course).

2. For me, CRUD goes in the relevant data gateway object - as I said, no DAOs in my applications these days.

3. Yes, multiple (workflow) services could indeed operate on the same business object. The separation by task means that maintenance focuses on behavior rather than "nouns". In reality, you don't need to find "all code related to users" because you have a rich user object containing all its behavior and then you have workflows that are relevant to the business domain and you're normally focusing on code to support a workflow or business process.

The trouble with the 1:1 (or 5:1) models is that you have very little coherence - the high-level "controller" (often an XML configuration in the CF framework world) ends up talking to several controller CFCs which each in turn talk to several service CFCs and that's much harder to work with and maintain because you can't look at a *process*. The 5:1 model also tends to create anemaic domain models because it pushes the focus onto the controller and service, both of which end up being fat and somewhat procedural and those just talk to dumb beans that do little more than contain data.

Of course there's also the reality that many of our applications are little more than basic data management so there aren't many workflows and the beans often *are* dumb by definition. I think that's why the 5:1 model has taken hold so firmly - it "fits" a simple data management app but it sure seems unncessarily complex. If all you're really doing is basic data management then the layering is counter-productive: you might as well have a simple controller per UI area and talk directly to simple data gateways for related groups of beans (and then the beans themselves). In other words, in the absence of workflows, the data layer pretty much *is* your service layer.

One object per verb can be useful in some systems, for several reasons. It certainly goes against the first instinct of OO, where everything revolves around verbs, but it's really a Design Pattern known as "Command", which has it's place in certain situations.

Last summer, I built an GWT application, which is a Java application that gets compiled to client-side Javascript. The program worked like this: a user did something to the UI, the application dispatched an RPC call, an asynchronous handler processed the reply, then any UI elements that changed on the server had to be updated on the client.

There were many problems when "verbs" were methods of "noun" classes (GUI Widgets). For instance, each "verb" requires at least two methods: one to do the RPC call and one to process the response. Second, and more seriously, users could sometimes trigger the same action by doing different things to different GUI components. Finally, a "verb" could cause several UI components to be updated, not just the "noun" that the "verb" supposedly belongs to.

The app was greatly simplified by creating a package full of "Command" objects that handled the various things users could do. The UI code would determine the RPC arguments and do something like

(new WhateverCommand(arg1,arg2,arg3)).execute()

and it was done.

Think of a web framework which has URLs like

/controller/{noun_id}/{verb}

The controller sees the {noun_id}, instantiates an instance of the {noun}, then calls the {verb} method. This is pretty simple, but it's got it's own conceptual problems. For instance, a verb can exist without any arguments...

/controller/logout/

There are basic conceptual problems when it comes to representing relationships in OO systems -- for instance, do you write

user.addCapability(), or capability.addUser(), do you write both? Is it

/controller/{user_id}/addCapability/{capability_id} or the other way around?

A conceptually clear approach is to write

/controller/{verb}/{argument1}/{argument2}/...

i.e.

/controller/logout
/controller/get/{object_id}
/controller/associate/{object1}/{object2}

"Verb" objects can work together with "Noun" objects to exploit polymorphism in simple, powerful and flexible way. For instance, the "get" verb could (together with helper classes) worry about cookies, headers, HTML and other webby stuff, then instantiate the object and call a much simpler "get" method on the object. You could also divide the "get" function into N phases with N different methods, providing an efficient way that object subclasses can override just one phase of the "get" function.

Stop worrying and learn to love objects!

Didn't have time to read all of the replies so I might be repeating -

The Gateway and DAO stuff was started back in 2003 as a fix and was not correct OOP. Cfc's have evolved since then, we should stop creating DAOs and place the CRUD in the Gateway object.

Service cfc's are great in the model layer as long as they ONLY contain business logic. A service cfc interfaces with other objects where the business logic has to draw on an outside source of data, such as a database for local data or webservices for remote data.

Data should be strictly under control of the model layer through its object services in this manner, webservices and etc also. Under the model directory then might be service cfcs, then a bean directory and a gateway directory. The bean directory holds object bean getters and setters, and the gateway directory has one gateway cfc for each table in the database. If you create DAOs your splitting your database table objects in two, wasting time and creating an overly complexed bloated file environment of redundant code.

I'm sure that this may or may not pertain to all situations but I have found peace since dropping my DAO habit and you will too.