I think that the standard design of ejb3 server-side is to create java classes for persistent entities which contain only data and getters and setters - business logic code is supposed to be somewhere else - in session beans.
But I wanted something more natural (similar to normal object oriented code where one class contains both data and related code) and also to get rid of all the superfluous session beans.
I thought that I could do without almost all of these session beans and I could have just
1) Entity classes containing both data and business methods.
2) One "gateway" stateless session bean which would enable me to remotely invoke methods of persistent entities. This is similar to how ejb2 worked: methods of persistent entities were remotely callable.
The idea is there would be only one session bean with method like
Object invoke(String entityClassName, Object entityPrimaryKeyValue, String methodName, Object methodParams)
This method would retrieve given entity (identified by name of its class and value of its ID) from JPA and then call its method of given name with given parameters using reflection.
Common application code would *not* call the invoke() method directly, that would be hidden job of proxy objects which would implement interfaces containing business methods. Proxy objects would just forward all calls to the gateway session bean and the gateway bean would finally forward the calls to methods defined in persistent entities.
I already implemented this idea and it seems to work fine. Is there any catch in this approach, do you think the whole idea is bad ?
Logic methods usually involves more than one entity. If your logic methods are implemented in entities you will get some coupling problems in this area.
I think that some trivial validation logic can be in entities but not complex logic.
This is my oppinion.
Please excuse my bad English.
I think you would do this in the same way as in object oriented programming in general - you have to pick one entity closest to the logic in question and assign the method to this entity.
if it makes your life easier, yes there is no harm doing it.
It's not mandatory to have only business logic in session bean and data in entity beans. Sometimes having them together makes sense and makes code easier, downside is , if you business logic change overtime, your beans could get real ugly and you could potentially run in to re-design issue. If you have a chance, take a look at spring framework, it solves these issues seamlessly.
What exactly is the "issue" you are referring to here and that Spring supposedly fixes? Could you, please, elaborate ?
Sou brasileiro, por isso vou escrever na minha língua.
Assim como eu preciso descobrir a de vocês, eu tambem nesse momento tomo a liberdade de escrever na lingua mais utilizada , para falar J2EE Entity Login Methods and Services na américa latina.
Bem.. o caminho com certeza é termos uma reflexão da matéria persistente, isso garantirá performance e concorrêcia pessimista.
No modelo de implementar usando Entity do EJB3.0, sinceramente, só dá pra acreditar em algo confiável, depois de conquistarmos a iteroperabilidade.No mínimo nas plataformas mais usadas, J2EE e .Net.
Antes disso, tudo não passa de mais marketing de ferramentas dos proprietários das VM's.
IMHO you are wrong.
How would you use it in MVC? Where is the Controller?
How would you use it in SOA?
Secondly how would you provide ACID (are you sure that the object is in a known state during a method invocation)?
What about transaction handling (when two or more Domain Objects are associated) when you change the state of more than one object?
What about security?
I see here serious problem with using OOAD principles mixed on both scopes the component scope and the system scope. You have decided to use EJB a Component Oriented Technology so you have to follow the rules that it advocates. My advice is to separate the OOAD on the system scope from the OOAD on the component scope. There is nothing wrong in Domain Object having responsibility but it is wrong when Domain Object provides some services (behaviour that involves transaction). I see the single business logic as a Service that the Controller should provide. Due to the OOAD it is the major principle after SSD (System Sequence Diagram) creation to specify controllers (services providers) that handle requests passed by UI Components. The conclusion is that we always pass data between the Controller and UI (View) not behaviours. I think it leads to more clear, scalable and effective system design.