Java Web Development Can Be Much Easier Then It Is Now

As you might have noted I started to publish my writings at talkinghubblogoforum. I just published my new article on JSF, Java web development, alternatives, and productivity. Welcome read Java Web Development Can Be Much Easier Then It Is Now.

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.

Waterfall 2006 Conference

Registration is open. Welcome to
http://www.waterfall2006.com/

For many of us who don't accept iterative processes by nature.

How to Write Software

I have an idea on a new set of articles on software development. What if I ask everyone on what the next killer web app will be, and start implementing it with publishing daily articles on how to actually write software from scratch? What if I ask everyone to participate? I will keep the design good and will ask everyone to make it even better. I will keep the development agile so we shall go fast. I will put the solution online as we’ll have a smallest piece to be put online, and we will evolve it to what we need.

So, anybody’s interested?

Singleton Considered Stupid

Thanks to Stevey for expressing my thoughts on Singletons.

Update: This is really fun. Read it all.

Hibernate author recommends not to use Spring Hibernate integration

Gavin King Says:

How to Write Comments

Last edited: 2006 January 16

Should I write comments? What is good comment? Is it possible to write comment for a class in 5 minutes? I would discuss these questions. I would be happy if, after reading, you will be thinking that good comments are an important thing to your project success.

I must admit that I hated to write comments. I was finding them boring and unnecessary. And the worse thing is that I was afraid that during my design some of my methods or classes might go away together with my time spent for writing my good comments. So the first thing I would discuss is


Why?

Here is the first reason for comments. Comments can make your design clearer. You could mark the class with its responsibilities using comments. You can check then how much your class respects its responsibilities, and that it don’t do something which is not its responsibility. Moreover, you can check how much your class respects Single Responsibility Principle and make some decisions to improve the design.

But I think that primary reason which can force you to write comments is to make your code understandable for others. The rule is simple. If you will hide your code for forever - nobody is going to know if it is commented or not. As soon as you are going to share your code with some other person - unless you are not writing it all together from the beginning - he or she will be happy to see your class comments.

Of course you could be happy to explain it to everyone personally. But you want to avoid phone calls asking what your class does while you are on vacation.

Updates are here!
Some person recommends to comment hard things. Absolutely.
Many people write comments for themself. Hire them now.

Do you know any other reasons which make you to start writing comments? If yes - I will be happy to include them here. Personally I find an important reason to have a good rest on vacation. So the next question will be -


How?

What is good comment? Should we judge how good the comment is by its word count? Should we have each method commented? I would say we don’t, or else our comments could end up time-consuming for us and being boring for our readers.

Antipattern

It’s so easy to mark a class with extended description of its name. We end up with class TransactionManager marked as Represents a Transaction Manager. Would this be descriptive enough? No sense to include this in comments at all. I can read a class name by my own. I would be more happy to see TransactionManager marked as Manages (creates, disposes and provides) transactions.

Personally I find very useful an old proven approach for class comments. CRC cards was used for a long time (since at least 1989) and hugely adopted with modern techniques like Agile Development (see http://martinfowler.com/articles/designDead.html and http://www.agilemodeling.com/essays/agileModelingXP.htm). We can take two good things from there and supply our comments with: class responsibilities, and class names our class is planned to communicate with.

Note that OO design tells our class to respect Single Responsibility Principle. Here is where your comment becomes an important design tool. If you find it impossible to name your class’s responsibility with a single combination of verb and noun – it is a good chance your class is taking too much on itself and should be split. One trick here is - use of manages helps.

Antipattern

Someone might want to describe here how other classes are going to communicate with our class. I would move this information into corresponding class.

We should end up with class comments which are pretty short but descriptive enough. And what about method comments? No clear recommendation for now. I would recommend to name a method as much descriptive as possible. It could make its comment unnecessary. I would mention some exception situations however. For example, I would describe what the method does if no item with given key available. Will it return null? Will it throw an exception?

Ok! Now we know which kind of comments we are going to write. Now the question is


When?

I dislike doing something which will be thrown away. I dislike writing comments which will be thrown away. During my design, I create new classes, play with them, throw them away and create new instead. I would find a way to save my time and write a comment when I have a decent hope my class will remain within the system.

The point to start writing comments is... when the code is ready to be presented for others. This could be the time before commit to a main source repository, or insert your case here. For this time, I have pretty stable class design, and good chance my comments will live long. I am pretty sure with my class’s responsibilities and what classes it will collaborate with. I can spend as much as 2 minutes writing this information as a class comment. Everybody’s happy!