The Single Responsibility Principle (SRP)

Simply put: A class should have one and only one task to perform. Or another way to put it: A class should have one and only one reason to exist. Object Mentor says it (and describes it) best at http://www.objectmentor.com/resources/articles/srp.pdf

The single responsibility principle is one of those things that sounds too theoretical. How can a class have just a single task to do? What if my system has 1000 tasks to be performed, do I have to create 1000 classes? Well, YES :-). And I am here to tell you that this principle works, in practice.

What did I gain by following this principle?

1. Improved the maintainability of my code: Since a class does only one thing, I can touch it w/o breaking any code that does other things. Simple :-)
2. Improved the extensibility of my code:

And the drawbacks?

1. The so called 'Class Explosion'. Your application may end up with too many classes to manage.
2. Yes, I can change code in classes without worrying too much about affecting other code, but first I have to find the code I need to change. And with myriad of classes it can get tricky to pinpoint what you want to change

A case AGAINST using Stored Procedures (and Triggers)

Many programmers are taught (and blindly follow) the "Stored Procedure" principle: If you have to insert/update/delete in a database table from a Java or .NET application, it is desirable to write stored procedures that do the insert/update/delete. The reasons usually given are:

1. Better Performance. The database server parses and compiles the stored procedure text once and re-uses the compiled string for later uses. This applies of course if you are using parametarized sql and you are not (god forbid!) using string concatenation.
2. By using a stored procedure, we allow the database server to also handle business logic, thus relieving the client site from processing.

This above reasons hold water for any RDBMS, albeit Oracle, MS SQL Server, Sybase, etc.

I would argue against using Stored Procedures. The main problems I have with the approach are:

1. The performance argument does not hold water at all. The database server will take the same resources and time to compile the stored procedure sql text, or the plain insert/update/delete sql text. The trick here is to use parameterized sql and not string concatenation.
2. The database is supposed to handle storage, not business processing. It's just not meant for programming logic. That is why we have the "Middleware", to handle our business logic.
3. By moving business logic to a stored procedure, then you are tying your business logic to procedural languages, and you are not taking advantage of Object Oriented programming concepts and techniques.
   The desired approach is to have all your business logic processing in the middle tier, or the client if you are working on a 2-tier system.
4. What about triggers? These are even worse. In my opinion triggers should NOT be used at all in an application. The only reason to use triggers is to get a new sequence number, and this applies only to Oracle. By having your logic dispersed in stored procedures, triggers and client code then you are decreasing the maintainability of your application.

To summarize, my advice is:

• Use plain insert/update/delete statements to update your database from your middleware/client code.
  Do not even create plain stored procedures that just do the insert/update/delete. In the future someone will have the bright idea to start writing business logic code in them. If they are there, they will use them.
• Use Java or any other Object Oriented language to encapsulate and capture ALL of your business logic.

By following the above, you increase the maintainability and extensibility of your application.

An MVC Checklist (Java)

Model-View-Controller (MVC2) and Model-View-Controller 2 (MVC2) are the de-facto patterns to use when developing Java and .NET web applications.

Here is a checklist to follow in order to apply the MVC pattern in Java:

1. Each of your JSP page (the View) has a corresponding servlet (the Controller).
2. Your database objects are mapped to "Model Objects", usually POJOs that mirror the database structure to Java Objects. (the Model).
3. From your web application pages, you have no direct html links to your JSP pages. Instead, your links point to the corresponding servlet of each JSP page.
4. Each JSP page posts back to its Controller servlet. In other words, the <form&ht; tag on your JSP page has the action attribute set to the Controller servlet url.
   Example: <form method="POST" action="/myServlet">
5. Each Controller Servlet handles/checks for "actions" and after processing, forwards or redirects to the JSP View Page. Here are some standard Controller Servlet actions:
   • "edit": where the Controller Servlet calls the Model which loads a record from a database based on same criteria, and then forwards to the JSP View page. The record is shown to the user available for editing.
   • "save": where the Controller Servlet loads data from the Http Request to the correspondind Model Object, calls a save routine and then forwards to a JSP View page.
   • "create": where the Controller Servlet calls the correspondind Model Object's create method, and then forwards to a JSP View page. This is where our uses can create new records.
   • "delete": where the Controller Servlet calls the corresponding Model Object's delete method, and then forwards to a JSP View page. This is where our uses delete records.

Here is the MVC diagram: (source: Wikimedia Commons)

The solid line represents a direct association, the dashed an indirect association (via an observer for example).