CHAPTER 12 ■ ENTERPRISE PATTERNSThis separation between Domain Model and the data layer comes at a considerable cost in terms of
design and planning. It is possible to place database code directly in the model (although you would
probably want to design a gateway to handle the actual SQL). For relatively simple models, especially if
each class broadly maps to a table, this approach can be a real win, saving you the considerable design
overhead of devising an external system for reconciling your objects with the database.
Summary
I have covered an enormous amount of ground here (although I have also left out a lot). You should not
feel daunted by the sheer volume of code in this chapter. Patterns are meant to be used in the right
circumstances, and combined when useful. Use those described in this chapter that you feel meet the
needs of your project, and do not feel that you must build an entire framework before embarking on a
project. On the other hand, there is enough material here to form the basis of a framework, or just as
likely, to provide some insight into the architecture of some of the prebuilt frameworks you might
choose to deploy.
And there’s more! I left you teetering on the edge of persistence, with just a few tantalizing hints
about collections and mappers to tease you. In the next chapter, I will look at some patterns for working
with databases and for insulating your objects from the details of data storage.