I am currently doing a small web application for one of my college's office, and I'm trying to do it as architecturally correct as possible. I have already created DAOs for database access and I was about to create my Bussiness Delegates. But a friend of mine told me that I should use a Facade to make a common place for method calls...
My question is, what is the real difference? I was thinking of putting the Bussiness Logic (registerUser, addCredit, blah blah) in one or more Delegates. So what do I need the Facade for? Should I call methods from all the Delegates in here? I really don't want to create a useless Transparent Facade...
Please use examples or code to illustrate.
Thank you very much!
[ January 05, 2007: Message edited by: Hector Pertierra ] [ January 05, 2007: Message edited by: Hector Pertierra ]
Hector Pertierra wrote: I'm trying to do it as architecturally correct as possible
Choosing a good architecture is always a valuable thing to do, but what worries me about the statement above is that it seems to imply that there is some single "correct" architecture. Architecture is just like any other aspect of a solution, it depends on the problem to be solved.
For example, in recent years there has been a big backlash against EJB, and one of the main reasons for this is that many people presented EJB as the single best architectural approach for all problems. That is obviously not the case, and has led to many overcomplicated, overexpensive, late and even failed projects. Unfortunately, some of the alternatives to EJB (Spring and Hibernate, Ruby on Rails, ...) are also being pushed as a single solution to all life's problems. That's just as wrong.
With that in mind, we are happy to help with your architectural decisions, but we really need to know more about what your application is intended for.
Ok, it's a really simple web application, used for assigning inscription turns for social service to college students. I'm using Struts 1.3 and didn't really plan to use EJB, Spring or even Hibernate.
As I said, I already made Data Access Objects that control all the DB access. I made Transfer Objects too and was about to make Business Delegates to encapsulate the actual business logic, calling its methods finally from the Struts Action Classes. But my friend told me that I should not communicate with the Delegate, but with a Facade instead, and that's where I'm confused. How does a Facade fit into my design? Is it really necessary?
I hope this is enough info. Thanks for your response
Joined: Jan 07, 1999
I'm afraid I have no idea what inscription turns for social service means, but maybe I can offer some suggestions on the rest.
I'll steer clear of Struts issues, because I have tended to keep away from Struts, and thus don't have much to offer.
With regard to a facade, the main value I have found to using a facade in a web application is that it can aid in unit testing. I'm a great believer in test-driven development (TDD) and like to unit test as much as possible of my software as early as possible in the design and build process.
User interfaces are notoriously clumsy and time-consuming to test, so to achieve my unit testing goals, I like to make the UI layer as "thin" as possible. Ideally I would have no logic in the UI layer. One way to achieve this is to develop the application and unit tests against a facade (also sometimes known as a model) which provides exactly the services needed by the UI layer. Such a facade can usually be developed in a way where it does not need to be run in a server, but can be tested with regular JUnit tests inside an IDE or from Ant.
Once the facade/model is developed and fully tested, it should be a simple matter to connect it to Struts and run some basic confidence tests that each Struts action calls the correct facade method with the correct parameters.
Where we might differ in architecture/design would be "inside" the facade. I would start by writing tests and developing facade methods, and only implement just enough database access and other stuff to make these methods work. I don't know how complex your business logic and data-access needs are for this project, but it seems it could easily be that you don't need the full set of DAO/DTO/Business-Delegate implementations. The trouble with starting from the "bottom up" is that it's hard to tell which of the facilities you are producing will actually add value to the project, and which will just take up space and time.
In a similar vein, the purpose of a Business Delegate is to hide remote method calls. Sounds like you don't have those, so you don't need the delegate. (As an aside, Business Delegates don't contain business logic anyway, as far as I can tell.)
I think you got seriously overboard with your architecture - which is nothing to be ashamed of, almost everyone who is new to patterns does that. But I think now would be a good time to aggressively simplify it - instead of adding even more layers of indirection.
In fact, I'd argue that the best way to introduce those patterns into an architecture is not by up front design, but by incrementally incorporating them as needs arise.
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Joined: Jun 06, 2006
LOL, I was afraid someone would say that... But you're totally right. This is my first real life system and I do think I might have exaggerated a little.
You have been really helpful so far, I got one last question though:
If the Delegate doesn't really encapsulate business logic and neither does the Facade... where do you think I should put my business logic?? I really don't want to put it ALL in the Action classes (it's a simple system, but not THAT simple).
If we had all those moving parts, they'd look like:
client -> delegate -> facade -> business model -> data access
The delegate exists to make life easy for the client. The client writes to normal Java methods that return normal Java objects. The client never knows if we are using EJB, RMI, XML/HTTP, sockets, or plain Java calls to the facade. This is a really nice gift to the client team if they don't know EJB. It's also nice insurance if you think you might change protocols.
The delegate and the facade usually have identical interfaces. That way the delegate can manage the protocols and nothing else - no business logic. I work on a system that generates delegate code just by knowing the service API so there can never be business logic in there.
The facade exists again to make life easy for the client. It provides a simple API so the client doesn't have to know the details of the business model. It might do a little logic making several business calls for one facade call, or making a highly customized result set exactly right for one screen out of generic business model data.
A facade is also works out nicely if the business model isn't ready yet or might change. I worked on a project with facades and we could fake up a method with hard coded output for the client team in a few minutes and then go design the real guts behind the method at our leisure.
Delegate and Facade are both optional. See if you can start without them until you find a problem they would solve.
A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
Joined: Jun 06, 2006
That was really useful, thanks a lot everyone
Joined: Jul 11, 2001
Originally posted by Hector Pertierra: If the Delegate doesn't really encapsulate business logic and neither does the Facade... where do you think I should put my business logic?? I really don't want to put it ALL in the Action classes (it's a simple system, but not THAT simple).
I don't know Struts very well, but I'd argue that the Action classes shouldn't contain any business logic at all, but only presentation logic. The business logic should be in classes that don't care about the fact that you are using Struts - and ideally could be used for a different presentation system (i.e. Swing) without much change.
Or we're reading more into "encapsulates" than the author meant. From the client point of view the delegate is all you can see. It exposes an interface and hides the implementation for protocols, business logic and everything else, which could be called "encapsulates". He doesn't necessarily say the delegate implements any of those things itself.
I sometimes see design like an architect's model of a building when they lift off the roof to reveal all the interiour. As designer of an entire system I can see down into all the paths through the building. But if you imagine yourself inside one room you can only see the walls and doors around you. Imagine yourself as a client who purchased a service in a nice shrink-wrapped box at Office Max. All you can see is the API on the delegate. The rest is, well, encapsulated. [ January 11, 2007: Message edited by: Stan James ]
Joined: Jul 11, 2001
Originally posted by Stan James: Or we're reading more into "encapsulates" than the author meant. From the client point of view the delegate is all you can see. It exposes an interface and hides the implementation for protocols, business logic and everything else, which could be called "encapsulates". He doesn't necessarily say the delegate implements any of those things itself.
True. It still seems to suggest that you should always have that delegate, which to me only would make sense for distributed systems.
Perhaps the author is using the term in a more general way, and not actually referencing the J2EE pattern. It sounds that what he describes is more like a Facade than a Business Delegate.
Joined: Jan 29, 2003
I finally followed the link to the Struts doc page and latched onto this: ...calls business services through the BusinessDelegate. The delegates in our framework have protocol strategies for remote EJB, XML/HTTP, raw sockets, POJO and more. They fit that line nicely. Their only purpose in life is to keep protocol code out of the client, the Action in the Struts picture. [ January 12, 2007: Message edited by: Stan James ]
Joined: Jun 06, 2006
I think that finally made it clear. I asked one of my teachers (yes, back to school) and he said that, of course, the Delegate should never EVER contain business logic; instead, it should contain the calls to wherever the business logic is, maybe using a Facade or a Service Locator (if needed).
So thank you very much to everyone again, and see you around very soon.