An Overview of The MLF

The MLF factors an application's model layer into three components: simple Java Bean-compliant objects called data objects that represent the entities of the application's problem and solution domains; a data object factory sub-layer that provides a public interface for the application to find data objects and to invoke business logic; and a data source sub-layer that encapsulates all interaction with the underlying data stores.

The MLF falls into the middle of a feature spectrum defined by EJBs on one end and the new JDO specification on the other. EJB technology is not a strict requirements-based alternative to the MLF. EJB technology provides powerful transaction management, caching, and distribution features that come with a high learning curve, complexity, and performance overhead. These powerful features are rarely required by the average business web application. Until recently, however, EJB technology offered the only Java specification model layer framework alternative to using low-level JDBC technology. This is a likely reason why EJB technology has been used too often when developing applications using J2EE.

JDO is a brand new Sun Java specification that stands for Java Data Objects. Like the MLF, JDO is intended to extend transparent persistence to Java objects. However, unlike the MLF, JDO is not yet suitable for most business application development because with JDO the database schema is generated from the object structure and is not independent. While it is possible to use JDO with an existing database, the facility for that is currently provided only by vendor proprietary extensions to the JDO specification. Additionally, all SQL is generated at runtime and is not available for tuning and each data object must map to one database table. Finally, JDO provides only persistence and related services, such as transaction management and caching, and does not provide any framework to support the development of business logic, unlike the MLF

The design of the MLF intends to balance two opposing development needs. One need is to provide a sufficient framework and collection of services, while the other need is to allow enough flexibility to adapt to the many different design and implementation approaches and application contexts under which the MLF may be used. Our approach in designing the MLF can best be described as similar to building sidewalks only after you see where the deepest paths have been worn. This approach, instead of designing the MLF to be a full-featured general-purpose model layer framework, has resulted in a framework that is easy to understand and to use.

The Features

·        Persistence

·      Inheritance – persisting a class automatically invokes the persistence of super classes

IMPORTANT:  By design, only saves and not regular deletes are propagated up the chain of inheritance. This allows more control over deleting subclasses and super classes. For example, if we have a manager that subclasses an employee, we may want to delete the manager aspect of the employee but not the employee itself. However, if deleting the employee is desired, it is easily done by finding the corresponding employee and deleting it after deleting the manager. An alternative is the full delete, which will propagate up the inheritance chain.

·      Multi-table – persists a data object to multiple underlying related database tables

·        Data Source Transparency

·      Private Data Source Layer – hides the data source specific implementation from the business logic and the application

·      Configuration Files  – places database specific information and SQL into configuration files to separate it from model layer code

·      Named Connection Pooling – unlimited named connection pools further decouple the business logic from the underlying databases.

·        Validation

·      Field – validation logic within a field’s setter method.

·        Data Type Size – generated

·        Custom

·      Object

·        Required Fields – generated

·        Custom

·        Flexible Data Object Views

·      Java Bean – data objects with fields and getter and setter methods

·      Collection – a collection of the preceding data objects with the facility to search by data object primary key or any combination of field values

·      Resultset – a JDBC-like view of a single data object or a collection of data objects. Interface is a subset of the JDBC Resultset class.

·      Rowset – effectively a disconnected JDBC Resultset. Takes a JDBC Resultset, extracts its data and meta data and presents a subset of the JDBC Resultset class interface.

·        Type-safe Enumerations – provides self-validating invariant sets of values of a specific type. For example, a subset of the enumeration of type InvoiceStatus may contain the values OPEN, INVOICED, SHIPPED, and PAID. The type InvoiceStatus  is an enumeration class that can be used in a type-safe manner as field, parameter, and variable data types, and can validate a value as belonging to it. Additionally, enumeration values can be declared statically in code or loaded at runtime from a data source.

·        JUnit-based Testing – JUnit-based test classes generated by a Forté IDE module

·        Two Layer Meta Data-based Code Generation – The majority of an MLF-based model layer can be auto-generated from a data object field meta data file. The code is generated in two layers – a regenerable layer and a custom layer. The regenerable (regen) layer contains the implementation for the data objects, while the customizable layer subclasses it. This approach yields all of the benefits of code generation with none of its major disadvantages.