Value objects, Services and Objects Frameworks

Still internalizing.

Suppose in your application you deal with assessments, standards and resources. Each of these entities would be modeled by a value bean and each of the value beans would have their own service which would have its own DAO and Gateway objects.

A quick review of the value beans reminds use that each has its own constructor method that returns a reference to itself (passing by reference). This provides a complete blue print of the object, with attributes and methods to the requesting entity. Best practices suggest requiring as little as possible to instantiate a object. Define the arguments as optional with default values. Each value object has matching getter and setter methods for each attribute defined by the value bean. The setter methods do not return any values or references, they simply update a instance value. The getter methods return a granular value, string, integer, boolean (passing by value).

A quick review of a service object reminds us that the constructor method also returns a reference to itself. The constructor method would likely have object instantiations to the dependent DAO and Gateway objects and methods to call the DAO and Gateway methods. The service would likely have a utility methods that would create a new instance of its value bean
, which would return a object reference. The service may also contain other utility type methods like data validation on a form. The service methods will likely contain your business logic or rules and may need to reference data in other value objects. Remember to think of your services as the social entities in your software ecosystem. They are the glue between your application and model layer and contain most of the business specific rules that your objects must obey.

In this example, suppose the assessment service needs to know something about the standard bean, it would need to talk with the standard service, now the assessment service needs to instantiate a pointer to the standard service. Suppose the assessment service also needs to know something about the resource bean, now the assessment service must instantiate a pointer to the resource service. This type of dependency is common and can become difficult to manage and debug when things go wrong. Architects often ask who's job is it to keep track of these things? Why does service a need to create pointers to service b or c and vice versa for objects b and c needing pointers to services a and b. This is complex and tricky and has given rise to model layer managers. The model layer managers, like ColdSpring or Livewire abstract knowledge from the service layer. The model layer manages the creation of objects and their dependencies. These objects are all singletons and need only be created once during a given session.