Is there any rule for implementing Design Patterns in Enterprise Environment.ie., What are the possible combinations of Design Pattern when we use it in Presentation Tier,Business Tier and Integration Tier.Is there any norms, that presentation layer must have Intercepting filter and Frontcontroller to communicate with Business Delegate and session Facade.Pls explain it briefly if it so.Thanx in Advance.
There is no set of static rules to apply in general to each application. It all depends on your requirements & how you want to associate your objects in interaction. During the process of design most of the design will fall into layers GUI,Business Components, Service components, Data access components etc. Once after determinig required Objects at each layer - you can talk about some Rules for example -
Good Practice of designing a Value Objects:
Always implement Serializable interface, as its sharable in distributed object mechanism
Do no place database Connection etc objects in a Value object as serialization will not work on such objects. If you have to put non-serializable objects mention them as Transient.
Always use appropriate data type, do not generalize everything as String
Make Value objects self-descriptive by teducing dependency with other objects
These are common rules / suggestions to keep in mind for Value objects.
So my point is RULES that you are talking about Design Patterns depends on Object type, its usage in a layered architecture.
I believe there are no fixed rules in implementing any Design Pattern. A design pattern is not tied to any language or just the IT world , instead they are just simply commonly tried and tested ideas of solving problems.And in programming world, programmers have over time found out that , if we tackle this business/ technical objective in a particular way, then it tends to be maximum maintainable, performing etc. So one have to identify the business mandates of the application(in IT world), and then find out the best way( usually it is a pattern) to build the most ideal system. And during the process , we employ various design patterns, which we might feel most suited to each unique scenario and code accordingly.
You and I can find out unique ways of solving a particular problem or developing an application, and the best feasible approach some times gets universal acceptance as they are the best known ways of solving such a problem or designing a system.
And that approach/idea about solving the problem/ developing a system or even a component is what I understand by a design pattern.
So the wise judgement about how to use which pattern( approach to the problem) is more important rather than complying to the so called design patterns.
Since J2EE was designed from the beginning with scalability in mind, it is usually a large system supporting multiple tiers.
It also means there are many pitfalls, which are usually overwhelming for an inexperienced J2EE developer(Maybe this is the main reason that many developers like .NET).
If you are an architect, you should take using deisgn patterns seriously.
The good thing is there are so many frameworks such as Struts,JSF,Spring and Hibernate that already employed lots of design patterns/best practices.
My approach is pickup a framework for the proejct and then my whole team automatically follows most of J2EE design patterns.