In the examples of my question, I assume the plain java has transaction / security control from its facade so there is no need to use other party tools.
n the answer about keeping the complexity down then using one big / fat session facade can keep the complexity down since clients only know one facade rather than many beans.
But since the components which the facade hides/delegates are not EJB and they are simply plain java codes then other tiers like web tiers cannot use it directly in instance it only needs it (not the facade, if web tiers use it directly
then there is no good separation between these tiers) and maybe some components needs to be moved to another subsystem then we have to again change the facade and the clients.
About Entity Beans, I heard many people suggest avoiding that since some application servers really have poor performance to handle it, and it is right as in the reply that it causes nightmare for performance due to activation/passivation/load/store of the bean. You are right; maybe JDO is better than Entity Beans.
the answer about keeping the complexity down then using one big / fat session facade can keep the complexity down since clients only know one facade rather than many beans.
That is the reason why you should use a facade, but also in the case of (local) entity beans as business objects.
facade can exist of several session beans, each session bean is a facade to it's business objects. So there is no big/fat facade.
This can be right, but I see in my experience that there is a trend to avoid using so many EJB / session beans or I would like to say a trend to avoid using so many (expensive) components.
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime. |