The blog has moved to a new location: www.freshblurbs.com

Doug has blogged about the new movie - Closer, recently.

I guess, he did not like it much, and since I trust his movie taste (and since I was REAL busy), I did not get it. Today, I was shopping at Costco and ran into Closer's DVD. Well, I really love Natalie Portman and respect Julia a lot, so curious to see what was so, quote, "badly-tasting" in this well-awarded (2 Golden Globes, 2 Oscar nominations) film, I grabbed it, immediately.

The movie is very well done. That, by the way, was in the quote Doug posted, too: "while his work, the script and especially the work from the four leads is solid to terrific, I just wish that their characters and the overall film didn't leave such a bad taste in your mouth and/or lead to the urge to shower after watching it due to all of the ugliness that's present." I can not agree to the "ugliness", part though. I would not expect SreenIt! to look only for bright colors in a movie. That would be too stupid. So what did they find so "ugly"?

I guess, it is a matter of - whether you can relate to the story, in the movie, or not.

If you married your college sweetheart, and lived happily ever after - it may seem "dirty", but not everybody is that lucky :) Things happen in life. Hey, life _is_ dirty itself. So, why should cinematograph try to brighten-up the reality? I do not like phony movies, much.

So, my final verdict - two thumbs up. Very well done, and did not seem like a movie, you need to shower afterwards, to me :)

" ROME is a set of Atom/RSS Java utilities that make it easy to work in Java with most syndication formats.

Today it accepts all flavors of RSS (0.90, 0.91 Netscape, 0.91 Userland, 0.92, 0.93, 0.94, 1.0 and 2.0) and Atom 0.3 feeds.

ROME includes a set of parsers and generators for the various flavors of syndication feeds, as well as converters to convert from one format to another. The parsers can give you back Java objects that are either specific for the format you want to work with, or a generic normalized SyndFeed class that lets you work on with the data without bothering about the incoming or outgoing feed type."

Persisting domain objects is one of the most challenging aspects of designing a flexible and testable enterprise application. There are lots of examples, in the industry, when developers get it wrong and end-up either with an effectively procedural, non-object-oriented structure and/or a highly complicated, tightly coupled design which is hard to unit-test.

Persistent Domain Objects Pattern gives a solution to resolve tight-coupling of the persistence and application logic code. PDOP decouples those by extracting the details of the persistence implementation and hiding it behind an interface, employing Dependency Injection techniques. As a result, domain objects do not need to know or worry about the details of the persistence code and can concentrate on their main task - delivering encapsulated data and behavior that models the domain under question. It, also, makes domain objects, much easier to unit-test in isolation from its dependency - persistent storage (e.g. database). Effective unit-testing increases the quality of a programming code and its extensibility.

Scope

Domain Model, Persisting Domain Objects.

Problem Definition

The core of most applications is their Domain Model. A Domain Model defines business rules (behavior) and the data that the business rules apply to. The behavior and the data are encapsulated into objects that form a hierarchy and can interact with each-other, thus effectively modeling the domain reality. For a wide-range of applications this Object-Oriented way of modeling the real-life scenarios works with the best, most effective approximation possible.

Usually, humans desire to interact with the model, in one way or another: influence the system or get a glimpse of what is going on. This is achieved via a View layer. Since the business rules (Model) change far less frequently than the user interface to the system (View), there is, often, a requirement of being able to change View without disturbing the Model. The requirement can be satisfied by decoupling Model and View through the introduction of a Controller. This brings us to the infamous Model-View-Controller (MVC) pattern.

If we could just start-up an application in-memory and guarantee that it always stays there, the above would be as much as we would have to worry about. Alas, that's not the case. We have to periodically (or constantly) backup a snapshot of the system's state into some kind of persistent storage. This way we can restore the state from the backup, if needed, or share it with others. The motivation and mechanisms, for the persistence, can be numerous and different but it is, almost, always necessary.

In fact, the persistence is so important that some people begin with the design of the persistent storage (e.g. DB tables) and end-up with an Anemic Domain Model and a separate "Service Layer" consisting of queries to the persistent storage. Martin Fowler et al. have identified it as an anti-pattern. Such tight coupling of the application code and the persistence one, makes it very hard to unit-test your application - makes application code less reliable and extensible.

Solution

One solution to the defined problem is to abstractly extract the concrete implementation of the persistence code out of the Domain Model. Basically: decouple the persistence from the application code. By decoupling, besides making our application much easier to unit-test, we will, also, make it more flexible - different persistent storage mechanisms (LDAP, DB, plain files, XML etc.) can be swapped-in on-demand, without affecting the application code and logic.

While we do this, we have a supplemental goal: we want to keep the implementation simple. One way of achieving the goal is to declare persistence as a dependency of a domain object. We can introduce a Manager interface that our domain object depends on for all its persistence needs.

Concrete implementations of Manager can be registered with the appropriate entities using Dependency Injection; so that the entity itself never needs to know the specific implementation used.

Sample Code

In this sample, we will look at a Blog entity. For the purpose of this demo, we will use the Context IoC introduced by Sony Matthew. The reason why we choose it over the Constructor or Setter Dependency Injection is to make example code simpler.

Let's look at the Blog interface. Please, note that the only addition to the interface, that would not be present in a "pure" domain object, is the declaration of the interface for the persistence dependency:

public interface Blog {

    public interface Manager {
        //-- The argument to the load() method is entity's PK
        public Blog load( String name );
        public void save( Blog blog );
        public void remove( Blog blog);
    }

    //-- The rest of the interface goes below
    // .....
}

public class BlogImpl implements Blog {

    private static Blog.Manager manager = null;
    public static Blog.Manager getManager () {
        return BlogImpl.manager;
    }
    public static void setManager ( Blog.Manager manager ) {
        BlogImpl.manager = manager;
    }

    public BlogImpl() {}

    private String name = null;
    public String getName() {
        return this.name;
    }
    public void setName( String name ) {
        this.name = name;
    }

    //-- Below go any other properties and methods relevant
    //-- to the Blog entity as a purely Domain Object.
    //.....
}

One of the manager implementations can have an implementation that looks like the following:

public class BlogManagerImpl implements Blog.Manager {

    public BlogManagerImpl() {}

    public void save( Blog blog) {
        //-- Save the state of the Blog object, into a database
    }

    public Blog load( String name) {
        //-- Load the Blog instance from a database.
        //-- e.g. using hibernate:
        //-- return (BlogImpl) session.load( BlogImpl.class, name ); 
        
        //-- this is just for the demonstration purposes
        BlogImpl blog = new BlogImpl();
        blog.setName ( name );
        
        System.out.println ( "Loaded blog: " + blog.getName() );
        return blog;
    }

    public void remove( Blog blog) {
        //-- Remove the persisted state of the object from the
        //-- database..
    }

}

public class Main {
    public static void main(String[] args) {

        BlogImpl blog, blog2;
        
        Blog.Manager blogManager = new BlogManagerImpl();;
        BlogImpl.setManager( blogManager ); 
        
        blog = (BlogImpl) BlogImpl.getManager().load ( "John" );
        blog2 = (BlogImpl) BlogImpl.getManager().load ( "Joanna" );
    }
}

each call to the getManager().load() will load an entity from a database. For the purposes of this demo, it, also, displays a message.

Conclusion

Using the PDO pattern, we have extracted the persistence code details out of the Blog entity. This made Blog entity more object-oriented. By decoupling its dependency (a database, in this case) from the entity, we made unit-testing the entity much easier. Better unit-testing delivers more reliable, extensible code and significantly improves the overall design.

On the left - Emmanuel Cecchet - Chief Architect for ObjectWeb, on the right - Jean-Francois Arcand - Tomcat 5 Developer.