Static layers in a java web application

Question

I am building a small website for fun/learning using a fairly standard Web/Service/Data Access layered design.

To save me from constantly having to create instances of my service layer/data access layer classes, I have made the methods in them all static. I shouldn't get concurrency issues as they use local variables etc and do not share any resources (things are simple enough for this at the moment).

As far as I can see the only trade-off for this is that I am not really following a true OO approach, but then again it keeps the code much cleaner.

Is there any reason this would not be a viable approach? What sort of problems might arise later on? Would it be better to have a "factory" class that can return me instances of the service and data layer classes as needed?

Answer 1

I would think that you will have concurrency issues with all static methods with multiple users. The web layer will thread out concurrent users. Can all your static methods handle this? Perhaps, but won't they constantly be locked in queuing the requests in single file? I'm not sure, never tried your idea.

Answer 2

You know those rides at the amusement park where they say "please keep your hands and feet inside the ride at all times"? It turns out the ride is a lot more fun if you don't. The only real trade-off is that you're not really following a true keeping-your-hands-and-feet-inside-the-ride-at-all-times approach.

The point is this -- there is a reason you should follow a "true OO approach", just as there's a reason to keep your hands and feet inside the ride -- it's great fun until you start bleeding everywhere.

Answer 3

The way you describe it, this isn't the "wrong" approach per se but I don't really see the problem you're trying to avoid. Can't you just create a single instance of these business objects when the server starts up and pass them to your servlets as needed?

If you're ready to throw OO out the window you might want to check out the Singleton pattern as well.

Answer 4

I don't really see the advantage to your design, and there are many things that could go wrong. You are saving a line of code, maybe? Here's some disadvantages to your approach:

• You cannot easily replace implementations of your business logic
• You cannot defined instance variables to facilitate breaking up logic into multiple methods
• Your assumption that multi-threaded issues will not arise is almost certainly wrong
• You cannot easily mock them for testing

I really don't see that the omission of one line of code is buying you anything.

It's not really an "OO Design" issue, but more of an appropriateness. Why are you even using Java in such a procedural way? Surely PHP would be more appropriate to this kind of design (and actually save you time by not having to compile and deploy).

I would just make your business layer non-static; it will make it so much easier for to maintain, change, and evolve your application.

Answer 5

You may have difficulty unit-testing your objects with this type of architecture. For example, if you have a layer of business objects that reference your static data access layer, it could be difficult to test the business layer because you won't be able to easily use mock data access objects. That is, when testing your business layer, you probably won't want to use the "real" methods in the data access layer because they will make unwanted changes to your database. If your data access layer was not static, you could provide mock data access objects to your business layer for testing purposes.

Answer 6

Disadvantages:

• You will be unable to write unit tests as you will be unable to write mock data access/business logic objects to test against.
• You will have concurrency problems as different threads try to access the static code at the same time - or if you use synchronized static methods you will end up with threads queuing up to use the static methods.
• You will not be able to use instance variables, which will become a restriction as the code becomes more complex.
• It will be more difficult to replace elements of the business or data access layers if you need to.
• If you intend to write your application in this manner you would be better off using a language designed to work in this way, such as PHP.

You would be better off going for non-static business/data access layer classes by either:

• Using the singleton pattern (creating a single instance of each class and sharing them among threads)...
• Or creating instances of the classes in each thread as and when they are needed.

Keep in mind that each user/session connected to your application will be running in it's own thread - so your web application is inherently multi-threaded.