Hi Jan, for the last couple of years I have been programming the middle tier both .net and j2ee. According to various blueprints adopted by major vendors we (me and my co-architecting co-workers) layered the middle tier in a business process - and a domain object layer.
Depending on the layer a differed set of pattern proved to be useful: The overall pattern in the business process layer is Strategy. That is there is no such thing as a final business process. Business processes are prone to continuos change because off various reasons and as a developer you just have to keep up. In order to avoid that a reengineered process doesnt integrate, the last approved strategy/process must be kept in production as a fall back option. Or because the same business in different setting is run in a slightly modified manner. The business process strategy may be refactored adopting various approaches and patterns. In case of limited complexity the template method pattern may provide an abstract high level view on the process that can easily be discussed with business analysts. More complex operations or algorithms are deferred to subclasses. An alternative approach to template method is the chain of responsibility pattern that factors the process into steps of self contained operations, what I think is particularly nice as a migration path to webservices and an service oriented architecture where business processes are orchestrated graphically. I highly recommend this approach when the business process is highly integrating in an enterprise landscape and rewriting a process is a sensitive issue. This would offer a more fine-grained way in reengineering the process. Some operations involve a lot of data a relational database is more apt to handle. Those operations can be wrapped in a command pattern that triggers a stored procedure. For the domain layer the facade pattern provides a set of methods that change state of the domain object. In a business world domain objects tend to be whole-part object hierarchies each class in that hierarchy representing an entity or table in a relational database. That is domain objects are likely to be implemented applying the composite pattern. Domain objects before stored in the database are validated applying specific business rules. The rules must be plugable and easy to code, so one with no big OO knowledge could do this. One possibility is by means of the interpreter pattern. However I learned that an organisation which primary focus is running a business that is not selling software would not be able to maintain the resulting codebase. A simpler solution is an abstract rule class that provides default implementations for all classes that make up the whole-part hierarchy of a domain object. A business analyst is required to overwrite the methods he wishes to implement. These rules are notified or called back by an observer when a particular method in the domain object facade is called. The observer implements also to Visitors one for downward traversal and one for upward traversal. A downward traversal for example is needed to verify that the foreign keys in the child entities are properly set. Upward traversal is needed to assure that subtotals on the order lines add up to the total on the order. The observer who acts in the role of an domain object controller calls a factory method which takes some attributes of the domain object provided by the process layer in order to determine the business case. Depending on the business case different rule sets are loaded and applied to the domain object. One has to distinguish between different business cases due to varying legal demands depending in which state, country, planet or universe the stakeholder wants to expand his business. Taxes on invoices may be one example: The States for the most part use sales tax, Europe instead VAT and Quebec a special state tax for what I know. Hope I could provide an overview on GoF patterns I use and in which context cheers Juergen > --- Ursprüngliche Nachricht --- > Von: "Jan Hannemann" <[EMAIL PROTECTED]> > An: <[email protected]> > Betreff: [patterns-discussion] Which patterns are more frequently used? > Datum: Tue, 5 Jul 2005 14:03:17 -0700 > > I'm wondering which patterns are actually used more frequently than others > in practice(*). In particular, I'd like to know which the top-5 (or > top-10) > Gang-of-Four patterns(**) are in terms of number of pattern instances > found > in practice. I do realize that this is hard to determine objectively, but > subjective rankings are fine, too. > > For example, I think it is pretty clear that Interpreter is less commonly > used in practice than, say, Observer. > > Are there by chance even research papers on this topic available? Or on > related topics (empirical study of patterns in the wild)? > > Opinions are welcome as well. A few years back I spoke to one of the > authors > of the GoF book and he gave me this informal list of what he thought were > the top-9 according to his experience (most commonly used on top): > > Observer > Composite > Singleton > Abstract Factory > Visitor > Adapter > Factory Method > Template Method > Command > > Can you confirm this list, or do you have different experiences with > patterns used in practice? > > Thanks! > > --Jan > > > PS: To provide some context: my research involves design patterns (in > particular, the GoF patterns) and I want to make sure I focus on patterns > that are actually used in software development. > > (*) With "in practice" I mean "in real-word software systems". > (**) I'm only interested in the GoF patterns. > > _______________________________________________ > patterns-discussion mailing list > [email protected] > http://mail.cs.uiuc.edu/mailman/listinfo/patterns-discussion > -- 5 GB Mailbox, 50 FreeSMS http://www.gmx.net/de/go/promail +++ GMX - die erste Adresse für Mail, Message, More +++ -- Weitersagen: GMX DSL-Flatrates mit Tempo-Garantie! Ab 4,99 Euro/Monat: http://www.gmx.net/de/go/dsl _______________________________________________ patterns-discussion mailing list [email protected] http://mail.cs.uiuc.edu/mailman/listinfo/patterns-discussion
