Tuesday, February 07, 2006

Persistence

Currently for me persistence is one of biggest difficulties in software engineering. One of reasons for it, I believe, is desire to make our business objects independent from persistence. This desire comes from recommendations of most respectful people in software like Martin Fowler. Many times I have read serious books on software design where author recommends: "There should be three layers like Persistence layer, Business Logic layer, and UI layer, and would be good to have Business Logic independent from Persistence because this way we’ll be able to switch from no persistence to file persistence or RDBMS persistence". "Good" I think. "Let’s make business logic independent from persistence".

First thing to note is that in most cases we don't need this flexibility, and trying to achieve it from start is against agile methodology and can cost us time.

Then we can ask what "Business Logic" actually is. When we write in requirements words like "New message from the User should be saved in the database" – is it business requirement or business logic or what? And we can agree that our categorization is pretty subjective - one can say "It’s a business requirement", and another can say "It’s persistence logic".

What I found is we can easily make business logic independent from persistence, but only when we have no word about persistence in our requirements. We model real world requirements in software, and having our persistence and business logic closely mixed in our requirements we can expect to have difficulties trying to model business logic independent from persistence.

Then I found that our business logic lifecycle actually starts from persistence. When our program starts, one of things it does first is it reads state stored in the database and initializes business logic with it. "What if I model my business objects like holding state given to them in constructor?" – I thought.


Persistence frameworks

I’m unhappy with today’s popular persistence frameworks. One of reasons for it is a fact that existing frameworks require my business entity to have getter / setter for every state data I want to have persisted. What should I do if I have some data I don’t want to have setter to, and moreover if I consider having public setters harmful?

Let’s take a quick example. Say I have Message entity which should maintain last modified date. First move would be to have lastModified Date field, have some update() method which will set lastModified field to current date / time, and call update() from setText() and other meaningful setters. This easiest approach would not work because my update() method will be called each time Message is retrieved from the DB! I will have to do some tricks to find out - do I need to update my last modified date, or it’s the persistence framework that calls the setter and initializes my object? Or worse – I will have to move lastModified management out of Message to some other object like UI controller.


So the idea is to have business objects to work with provided state. I will be testing this idea for persistence. Business objects can be made having no idea if the state is going to be persisted or no – yes, this way I can make them independent from persistence! State is responsible for persistence. It will persist itself as it decides to.

2 Comments:

Anonymous herbrandhofker@yahoo.com said...

Hello Denis,
I read part of all your thoughts this morning, and I focus in this comment on the persistency/business rules in combination with the j2ee/jsf approach.

In fact I am struggling in the same area.
In the period 1985-1994 I was developer for USoft (see USoft Business Rules, NIAM) and we based business rules on sql (based on set theory) , and we added a smart giu on it (x-windows and later windows)

Then webdevelopement become dominant
and a lot of parallel developments result in a lot of good and bad things.

I try to get this sorted out, now for 3-4 years to come to an elegant good approach. I started company in Chernivtsi to get this done (urksoftlab), but because we need to produce something for our customers we had to choose some framework (Java j2ee jboss postgres) and we produce good things.

But continuously the feeling is : it can be done much better.
I investigated jsf myfaces one year ago. It seems I have to do it again it is now more mature. I am continuously investigating using databases much more, so not using a persistemt layer as I see it is duplicate logic built in.

Also the Ajax problem is on our future path for richer clients, as is SWT RCP in eclipse.

My problem is that I have all these ideas but I cannot do it alone. I have brilliant guys working but overloaded with work.

Now I found you with similar ideas and looking in similar directions I wonder if we can join in these efforts somehow.

Hope to hear from you.

Herbrand Hofker

Sun Apr 16, 11:54:00 AM GMT+3  
Blogger Denis Krukovsky said...

Herbrand,

Your story is interesting. I will not pretend that my experimental persistence approach is a silver bullet for persistence. I just pointed on some problems with common persistence frameworks and built my service's (talkinghub) persistence without those problems.

What I will pretend however is that Java web development have a lot of things which can be done better, faster and easier, and talkinghub is live proof of it.

I'm always open for discussion and collaboration.

Mon Apr 17, 06:44:00 PM GMT+3  

Post a Comment

Links to this post:

Create a Link

<< Home