Jan 29
Services, DAOs and Functional Organization
Illudium , Modeling , Application Architecture Add comments
While cleaning out the office recently, I ran across a couple of textbooks I kept from my business school courses. I didn't care much for business school, but I did learn some valuable concepts. A few of which came from a course on Organizational Behaviour (OB). OB is a "management science" which can be briefly described as the study of groups in organizations. A goal of OB is to determine the best strategy to use within an organization to maximize employee performance (productivity) and, as a result, profitability. If you think of an organization with managers and employees, where each employee performs specific duties, you might find it strange to have a manager for every employee. You rarely see this in the real world, because it is grossly inefficient.Let's pretend for a moment that we have an application for a fictitious Accounting department, where Services are managers and Data Access Objects (DAOs) are subordinates. For this example, our DAOs are filing clerks, who's sole duty is to file and retrieve records of a particular type (Orders, LineItems, Invoices and Payments). In our application, Orders have 1..n LineItems, 1..n Invoices and Invoices have 0..n payments. Here's an example of how you could set up your application.
When each DAO has a Service, we end up with a vertical or 'silo' approach to our application. A major drawback to this approach is that the coordinated effort required to produce an Order, or Invoice document requires that multiple Services communicate in order to achieve the desired result. And, in the case of the Invoice and Order Services, we have a bi-directional relationship that represents a circular reference.
If we change the Accounting depart to have a single Service and increased the Service's span of control over subordinates, we can coordinate the DAOs effort without the inter-service communication dependencies. This is a lot closer to what you would see in a real world Account department. One manager for several clerks. An immediate benefit of this design, is that it allows you to control saving composed objects as transaction without having to manage that transaction across services.
When I first started with object-oriented programming in ColdFusion, I quickly found productivity gains by using a code generation tool. Brian Rinaldi's Illudium is a great tool for generating anything from cfcs to configuration files from database introspection. While this is a boon, it can also be a trap if you don't use the tool wisely. On many occasions, Brian has made it clear that Illudium is a productivity tool, not an application modeler. I still use Illudium to generate code, but I always re-organize the code in a way that helps achieve both a smaller code base and more functionally organized application.
When each DAO has a Service, we end up with a vertical or 'silo' approach to our application. A major drawback to this approach is that the coordinated effort required to produce an Order, or Invoice document requires that multiple Services communicate in order to achieve the desired result. And, in the case of the Invoice and Order Services, we have a bi-directional relationship that represents a circular reference.
If we change the Accounting depart to have a single Service and increased the Service's span of control over subordinates, we can coordinate the DAOs effort without the inter-service communication dependencies. This is a lot closer to what you would see in a real world Account department. One manager for several clerks. An immediate benefit of this design, is that it allows you to control saving composed objects as transaction without having to manage that transaction across services.
When I first started with object-oriented programming in ColdFusion, I quickly found productivity gains by using a code generation tool. Brian Rinaldi's Illudium is a great tool for generating anything from cfcs to configuration files from database introspection. While this is a boon, it can also be a trap if you don't use the tool wisely. On many occasions, Brian has made it clear that Illudium is a productivity tool, not an application modeler. I still use Illudium to generate code, but I always re-organize the code in a way that helps achieve both a smaller code base and more functionally organized application.
Jan 29, 2008 at 11:44 AM Couldn't agree with you more. I personally never create a 1 service to 1 object/dao pattern but rather a single service that comprises what I refer to as a logical entity within your application. I still use Illudium to do this but often it is more copy/paste for services than "save to file" if you know what I mean. Plus the service I generate is kinda dumb...its just some stuff that you probably need but not all stuff and it has no business logic for obvious reasons.
Jan 29, 2008 at 12:48 PM Exactly! A fine example of what I've been trying to get across on some of the lists recently when questions about Services and generated components comes up. It's important to remember that the services that the model makes available will almost never correspond in a one-to-one way with the underlying database tables.
Jan 29, 2008 at 2:19 PM @Brian R - sounds like we have the same work flow going on. I like it!
@Brian K - Thanks! I've followed the lists and agree with you on that point completely.
Now I need to come up with a semantically meaningful name for the Service that manages all my static data lists, like Country, Province, Region...
Jan 30, 2008 at 7:30 AM Personally, I have a ValueListService that handles both my static and dynamic value lists. Static lists it contains the values. Dynamic lists it contains th object name, method name and properties for the title and value fields. Seems to work out pretty well . . .
Feb 5, 2008 at 8:49 PM An interesting variation of the ValueListService is where the value lists are actually stored in the database - a must for direct-to-database reporting and data extraction, but a pain in the butt for application programming. I think it's a huge mistake to wire these value list tables into the domain ORM model, as that then makes the individual values into first class domain objects, which often is wildly inappropriate. Enter the ValueListService, complete with composed DAO.
Feb 5, 2008 at 8:58 PM Hi Jaime,
I store the value lists in the database, but I specify them in the ValueList business object as initial data (using XML). Then every time I build a database, it create the table to hold the value lists and then loads the value lists from the XML to the new db.
I find this works great for me. I describe a value list as some combination of static, databased and calculated data. Static is if you want a list of states (which will be stored in the valuelist table), databased is if you want a list of pages or users or similar - you describe the business object, the method to call, any properties (for filter and/or order) and the property names of the title and value properties for that list, and if you want calculated, you just name a method that will return the appropriate values (e.g. for a list of years for a credit card which will typically be the next n years).
Seems to work well for me so far . . .
Feb 5, 2008 at 11:29 PM It's a good thing I don't have an option to disallow comments from people smarter than me. I'd have no comments!
@Jamie, I can't thank you enough for pointing out the folly in elevating static list data into domain objects. I've gone down that path not realizing the peril.
Feb 23, 2008 at 12:52 AM Hi there. I'm a student of Informatics, and I'm learning software engineering now. I have a question for you guys.
I'm working on a mega-application with over 2000 entities. Now, we have an architecture defined, where we use a DAO and a service for each entity, and we have a facade for each module. Here, making a service that manages many entities cam be complicated, a it would result in overloading that service and making it hard to understand and to support, however, communication between services is not required to load an object from the DB because we use an ORM (Hibernate), and it manages object relationships very well.
Now, my question is ¿what kind of logics should I put into the services? ¿Should I put any kind of logics related to the entities, such as associating new objects to an entity or iterating over a collection association to do some processing? ¿Or should I only put there the logics related to loading/storing entities from the database (communication with the DAO)?
Feb 28, 2008 at 12:42 AM Hi Jose,
As I understand it, Services form your public API and provide methods for managing related groups of objects. So, the facade that you describe for a module, is more like the Service I'm using in my example. How have you broken out your modules? Is it possible to have your services communicate directly with Hibernate and not use a DAO as an intermediate? Generally speaking, services should coordinate the storage and retrieval of objects either directly with an ORM or through a DAO that encapsulates the ORM. Services also provide other support such as notifications, logging, reporting and security.
I hope that helps!
May 6, 2010 at 4:44 PM In my opionion, the first "1-1" diag is correct, however you should create a factory of all those services and call it "accountingFactory" combined with active record...