General J2EE: Using Business Delegate in a non EJB environment
- Posted by: Narayanan M
- Posted on: December 07 2004 10:31 EST
Posting this here because I am unable to post a message in J2EE Design Patterns forum.. Its giving me an error..
I am designing a system without EJBs in it.. and I am planning to use Business Delegate pattern here, just to hide the DAO access logic from the Action Classes.
But, wherever some one talk about Business Delegate pattern, it is in EJB environment..
I want to know whether it is ok to use Business Delegate pattern in a non EJB environment.. Could anybody give your valuable inputs..?
Thanks in Advance..
- Using Business Delegate in a non EJB environment by Shaha D on December 08 2004 10:45 EST
- Using Business Delegate in a non EJB environment by andrea boriero on December 22 2004 13:05 EST
- Business Delegate to Hide DAO ?? by Vee Gee on December 22 2004 15:33 EST
A business delegate essentially can expose any business service. Take a look at session façade pattern also and make sure using a delegate is more appropriate in your case.
Thanks a lot for ur valuable time and response..
Invite any other comments as well..
I agree with Shaha. These patterns are not coupled to EJB and can be very appropriate outside of EJB. As Shaha said, consider a session facade instead. A delegate is typically used to hide the complexity of calling your business logic. If you are using EJB this would be the case, but for POJO, probably not. Session Facade is typically used to create a single entry point/abstraction to your business logic. In EJB the facade typically is also a Stateless Session Bean, but for POJO, this can just be another layer of abstraction/grouping and can make things clearer (or unecessarily complex). In EJB Session Facade is also used to minimize network round trips between your client & EJB container, but that is not necessary for POJO.
It is absolutely OK to use the Delegate Pattern in a non-EJB environment.
Business Delegate is to reduce coupling between client and business layers. Any situation which warrants such a coupling could use the Delegate Pattern.
A pattern, I believe cannot be associated with any technology in particular. It is a solution to a problem in a defined context.
i try to use the business delegate patterns for the first time . I don't use EJB but POJO object. Looking for information about the best usage of business delegate and other related patteren i found this Discussion that arise in me a doubt: it's possibile to use both business delegate an session facade? for example i have to encapsulate in one transaction calls to different business object, in this case the business delegate can use the session facade?
Excuse me for my english and for my ignorance about patterns
i'm trying to improve my knowledge...
thanks for help
Links to explain these patterns:
You can use both of these together, but you should justify the need for doing so. In the EJB universe the both serve a purpose.
The Business delegate is used to hide the complexity of making an EJB call (or multiple EJB calls if you don't use a session facade). It can also be used to make an absraction of calling you business logic. If you move from calling an EJB to making a web service call then only your delegate has to change. It's useful to remove this type of thing from the UI code. These objects exists in your UI layer
The Session facade is used to centralize a call to your EJB. This has a few benifits. First, you get the abstraction. The Session Facade doesn't need to change even if the way you implement the business logic changes. Second, a more EJB related issue is that it can give you one network hop where-as if you you were calling 2 EJBs to do your transaction you would have 2 network hops. Its also a good place to control you transaction from. These objects exists in your business layer.
If you are not using EJB, but POJO, you need to ask why you are creating these. For a complex, data intensive transaction you may want to take the time to do both a delegate and a facade. Especially if you think this might be an area that changes a lot. If the transaction is simpler and will likely not change very often, you may want to get rid of the Delegate. If you initiate a business transaction from more than 1 place in the UI, then you would want a delegate to have only 1 place where this is called.
Whichever level of these patterns you use, make sure you understand the purpose of each and limit those classes to that purpose. Don't start putting validations in the facade or delegate. Make sure that is in you business logic implementation classes. Don't put anything relating to the representation of data in the delegate. That belongs in the UI.
The delegate is just a class that receives a request from the UI and fowards it to the business teir. The facade is just a class that receives a request from outside the business tier and forwards that on to the classes the implement your business logic maybe controlling the transaction.
thank you very much for your help
One of the primary functions of Business Delegate pattern is " Identifying the Business Service". Invocation of service happens only after this step. With this in view , to hide DAO may be a Facade should do good