I was curious what the opinion was on using nested classes as a dao pattern. Tell me if you shriek in horror at this idea. To me it seems appealing, especially when using a generic base dao (which I am assuming here are also following this nesting convention). This appeal could very well be due just to me dislike of many 3-4 line class files, not that I am advocating monolithic classes either. Without a generic dao class, this could very well become unwieldy.

The static nature should limit undesirable issues with excessively promiscuous member access.

A contrived example.


A contrived usage.


Please give me all the reasons this is why this is never done. :)

That pattern completely destroys the separation of concerns that having a DAO is intended to promote.

If you're going to go with a pattern like this, why do you have the DAO interface at all? The implication is that you'll only ever have the one impl, so why bother with the interface?

What does nesting the DAO inside the POJO do for you that good old fashioned static members wouldn't?

So now you're down to a POJO with static members for fetch, create (perhaps), update, and (perhaps) delete. Nice and simple, if you don't want/need a separation of concerns. Personally, I never have the luxury of making that many assumptions.

Another note I have is that this sort of pattern assumes 1 DAO per Entity, which isn't usually necessary - assuming that you map associations properly in hibernate, a DAO for the 'root' object classes in the application is sufficient, plus perhaps a couple for special situations that crop up.

Thanks for the replies.

Cristian, I actually use your generic dao already and think its great. Combined with an implementation that also uses Spring, I end up with something I am very satisfied with. The result has been that my dao classes have mostly shrunk to 1-4 lines and the one-file-per class approach, advocated in the land of Java, does seems somewhat pedantic.

The degree of nesting can be flexible depending on the case at hand. At the least, nesting the implementation within the interface doesn't seem like a crazy idea.

I do not see why this destroys the separation of concerns. Yes the classes share the same location, but they are still handling their various responsibilities in exactly the same manner. I will concede that imports are now less specific: the dao is exposed to the client class when importing the pojo, but its not quite wide open. If anything, you could just nest the dao/impl alone and avoid this side effect. However, wildcard imports achieving the same result and I do run across them.

There is also nothing to stop you having multiple implementations, though some might argue that this would lead quickly to overly large files.

I must admit I come from the land of C/C++, where good or bad the per file convention is not enforced by the language. Maybe I have terrible habits, but I like to think that I am fairly introspective and rational about things. This thread is to gather opinion. Perhaps I am over compensating for what I consider a tendency for rather anemic pojos. Take away get/set from some projects I've seen, and the classes are simply C structs.

The point is that your domain classes should not have inline DAOs. The right place to do this is the DAOFactory.

Ah sorry, I went there thinking I'd see an inline class in the factory but didn't. I am guilty of skimming I believe. :)

Separation of concerns is more than just allocating responsibility to classes - it's also about allocating responsibility to different architectural layers, and making sure that the code is running in the right layer.
You don't necessarily _need_ a completely layered architecture in all cases, but as I was saying, in those cases, nesting inners doesn't buy you a whole lot.
Now, I'm a big fan of inner classes, but that's more in cases where I can make use of the inner having visibility to the outer classes members and final local variables. I look at these cases as the outer and all of his inners as collaborators in the same concern, though. Kind of a multi-headed beast.


Well file size (in my book) is the lesser consideration. If you have all the implementations in one place you're giving yourself a pretty diluted version of the plugability and clarity of separation between contract and implementation. You're liable to wind up with a tighter coupling than you really had in mind as the software evolves over time. Again, if you don't mind tight coupling, why introduce the interface at all?



The only difference between C++ struct and class is the default visibility of members. In Java, there are cases where I make data members public and javadoc the class as a 'struct.' These are always small classes, usually private to a subsystem, though. As far as real entities go, I've had too many occassions (back to my C++ days) where something got hosed because of a lack of control over what got put into a data member, or fields that were simple data become calculated or need a check ...