Beans, DAOs, Services, applications

Im working on a Utility that does standard CRUD stuff. My brain got a little confused, again, in the area of relationships between services, beans and DAOs. Specifically, i could not decide the best way to implement the relationships between the three. In a SOA, we use the Service object as the laison between the application and the domain objects. Does the service also keep the responsibility of creating a persistence bean for a certain object? I think so, i added the instantiation of the resource persistence bean into the init() of the service. Now the service init() function instantiates DOA, Gateway and bean objects. I am using the variables scope in front of each and have tested the threading, which should not be a problem, since each user who instantiates their own service object gets there own copy of each of the other objects.



In my service, I have a set bean method, that updates the "empty" bean object, by passing a objectID into the set bean method - which then goes to the DAO, since thats the object that should have the SQL or whatever DB code you are using. The bean itself should not know about the database that is being used to get its data so it can do its job of persisting. So, the service calls a getRecord method in the DAO, the DAO sends back a 1 record query to the service. Teh service checks to be sure it has a valid result and then passes the query result to the set bean method in the bean itself.



This seems to make sense - following these good OO practices.

• Service creates objects needed to do the work requested by application
  
• Service asks the DAO to get a single record, passing in objectID
  
• DAO returns a single record
  
• Service ensure the record returned is valid (this could be done in DAO too)
  
• Service then calls the set bean method in the bean itself, passing in the record to update
  

In conclusion:

• The DOA does not know about the beans
• The beans do not know about the database
• The service knows about beans and DAOs and Gateways and other services.

new development

Im about to begin development on a medium sized project and wanted to document some of the things i know i should be thinking about before i begin.

Who is my customer - define this, have them in your mind. You should be able to say in a couple works who they are.

What do they want - get a requirements document nailed down. Thats happening now, my customer is detailing the requirements from our meeting, he will share those back with me for agreement before giving to his client. Be very specific about what the specs indicate will be done in the initial iteration. We could use a front to back design methodology that gets the product in front of the client sooner than later. We may still try to do this. I am following the Agile approach, not the water fall. In other words, create smaller more focused iterations of the product, rather than larger more consuming ones. This is a tenent of good design or process.

Getting down to business. I will follow a mature design pattern, MVC. This pattern will focus on the separation of functionality into three distinct pieces. Think usability in the view layer. Ensure the interface is easy to use, clean and reliable. Not too much clutter or needing to dig to see things. Provide immediate feedback in the interface. Perhaps use AJAX type functionality. This will be a data intensive application, so AJAX techniques would be valuable. At the same time, be sure the application works in both IE and FF. AJAX stuff sometimes is cross browser problematic. I could use the built in CF8 AJAX libraries, but this would require that the hosting server would also be using CF8, which is not quite true, yet. I should stay away from cf8 specific functionality for now.

The controller. I will probably use machii or some MVC framework. Other utilities and the main application all use machii. I *could be consistent or i could use as opportunity to try a different framework, like model glue or Tarten. I could forgo a framework all together, but i like what the framework provides and I know that this application is going to grow in complexity.

The model. This is the part that is most interesting to me. I do like the other layers, but the domain modeling and service, DAO, bean objects are of most interest. I have implemented these patterns a few times now and each new opportunity provides more insight and hopefully a tighter design. I could even try to use a ORM tool to stub out the intial domain objects. The domain design includes how to manage the relationships between the collaborating entities. I will probably use ColdSpring again, since i just think its a superb piece of engineering. Maybe i wont use CS, and show how the objects themselves could keep that knowledge, via init and constructors.

Ill return in a couple weeks when im done with the initial build of this Utility.

Reflection - training new developers

I have been helping a co-worker do some work that has really caused me to look at some high level principles. I like this, and wanted to capture some of the thoughts. first off, we are following the SOA design patterns in our development. this to me means - creating a service oriented architecture, where the service objects are the big dogs in the playground. they are at the conceptual front of the domain line. They are who is called when some application wants to get at some data.

In our application, we are using machii, so there are listeners that are registered as part of the application. Whenever the application does something - it is funneled through the controller (a xml file) in the form of an event. If the event needs to speak to the data layer - then is uses one of the registered listeners to do that.

The listener has lots of functions in it and has *knowledge of the event and the arguments or parameters *URL variables that are passed around (this is usually either URL or form data served up by a view page. The listeners job is primarily to pass things along - pieces of data that the service will need that determines what to do with it.

This is know as the bus. logic and should live downsteam from the application and listeners. The bus. logic should live in the service and in the persistance objects.

So, while helping my co-worked to understand all this abstraction of layers - i found myself using works like design patterns, service oriented architecture and persistence beans - including anemic -vs- rich beans. When you have to explain to someone why things are how they are, it makes you think very critically about the why portion - and you better have more than a "because thats how i found it" response.

I am also using coldSpring - so i talked about where the service gets its knowledge of things from. rather than the service objects creating its dependent objects itself - that knowledge is abstracted from the collaborating objects and into a *container xml file that does it for you. Brilliant!. I do like coldspring alot! I talked with her about where this new piece of bus. logic should go and where it should come from and why. It was a neat experience.

Im not saying that i have all the answers or that the answers that i have are perfect, im just saying it felt good to explain this stuff and to see her seem to get it.