The flip-side of Patterns, AntiPatterns provide developers with formal descriptions of common development gaffes that can derail a project along with practical guidelines on how to avoid them. In this book, the authors present dozens of Java AntiPatterns that tackle many of Java's biggest trouble spots for programming with EJB, JSP, Servlets, and more. Each AntiPattern is documented with real-world examples, code, and refactored (or escape-route) solutions, and the book uses UML (where appropriate) to diagram improved solutions.
- Posted by: Bill Willis
- Posted on: August 01 2003 23:10 EDT
Two chapters are available for download:
Chapter 2 - Persistence AntiPatterns and Chapter 5 - Servlet AntiPatterns.
You may purchase the book from the Wiley Bookstore or Amazon when it becomes available.
In particular, I've encountered the scenario where deep read-of data (not lazy loading) was used and caused the system to grind to a halt under load. Also a factor was a suspect persistence mechanism that was using too many concurrent 'pooled' connections.
I like the attention payed at the Architectural level.
John C. Dale
I don't think DataVision is an antipattern; I think it is an artifact
of the E-R / OO clash, and this part of the book is an argument in favor of
the O-O side.
The author correctly identifies the religious war between E-R and OO
worldviews and their adherents, and acknowledges that "neither world
should be responsible for dictating the designs of the other".
Yet in the next section, he states: "If possible, let [a component-oriented
perspective] drive the design of the underlying database schema".
This is the opinion of an Object Bigot, not a problem solver.
Furthermore, the antipattern example -- propagating a many-many mapping
table in the db to its own class -- is atypical and simplistic.
O-R mapping has two levels, logical and physical. The domain is captured
in the logical layer, and the physical is derived mechanically.
Such a many-many table would not
exist in the logical layer; it is instead a physical implementation detail.
Besides, I've never seen Address as a separate entity for Name - usually,
many-many relationships between REAL entities DO need to be reflected at
the object level as some sort of efficient map.
Which really drives to my main point - sometimes the object IS just data.
What sort of behavior could a Name or Address class have which is so important or subtle
that anything other than an accessor needs to be used to encapsulate it?
Many problem domains (including Financial Services, which is my profession)
are defined by mathematicians and procedure-oriented people, rather than
occurring in nature, so modelling them correctly IS an E-R exercise.
I much prefer Martin Fowler's treatment of the E-R/OO clash in his
"Patterns of Enterprise Application Architecture"; he accounts for
data-centric problem spaces with his Data Table pattern and gives guidance
when it's more appropriate than an Entity Model approach. And Fowler
freely admits that he's an object bigot!
From your post:
> The author correctly identifies the religious war between E-R and OO
> worldviews and their adherents, and acknowledges that "neither world
> should be responsible for dictating the designs of the other".
> Yet in the next section, he states: "If possible, let [a component-oriented
> perspective] drive the design of the underlying database schema".
> This is the opinion of an Object Bigot, not a problem solver.
I would respectfully disagree. He is a problem solver just with a different tactic and view. If he goes the E-R approach, then he ends up with a data model that is more data oriented and tries to map that into his OO world. If he goes the OO component approach, he gets a data model that is more OO, but is pretty easy for the database to deal with, for example, to create a custom "view" for that is more data centric for the needs of the data oriented users. He pushes the responsibility for taking advantage of the database features, etc. to the correct layer and uses the one of the best features of OO (components) in it's layer.
This shows some understanding of the power that can be applied at each layer and understanding of the strengths and weaknesses of each toolset and how they can be applied creatively without corrupting either layers model in a manner that forces one approach into another.
The idea of view it as a component is the correct approach given that you typically want other components in the application or enterprise to be able to work with that data via the objects using the application servers space and to not push his applications specific data modeling optimizations onto all other applications that need that data. Thus the component view doesn't optimize for data performance via the data model. He is modeling the application at the compenent view. Additionally this allows him to insulate all other users from any optimizations that he may want to do to the persistence model later on. Such as taking advantage of "views" to increase specific query speeds, what have you. And at any later time, he can create specific optimizations to that model both at the OO component layer and at the data layer without having tied any other application or component into his original data model.
One other way of looking at it when he says to let the component oriented model drive the db schema if possible, is to think of it as a premature optimization. Properly done, a component model is going to give you a very good flexible 3rd or better normal form DB. Without any optimizations at first. This is what your supposed to do anyway to start with.
His advice is sound given these and other concerns I've not expressed.
Sam Griffith Jr.