Because of the relative sophistication available when using shelve, our application software must become more properly layered. Generally, we'll look at software architectures with layers such as the following:

• Presentation layer: The top-level user interface, either a web presentation or a desktop GUI.
• Application layer: The internal services or controllers that make the application work. This could be called the processing model, which is different from the logical data model.
• Business layer or problem domain model layer: The objects that define the business domain or problem space. This is sometimes called the logical data model. We've looked at how we might model these objects, using a microblog Blog and Post example.
• Infrastructure aspects: Some applications include a number of cross-cutting concerns or aspects such as logging, security, and network access. These tend to be pervasive and cut across multiple layers.
• Data access layer. These are protocols or methods to access data objects. We looked at designing classes to access our application objects from the shelve storage.
• Persistence layer. This is the physical data model as seen in file storage. The shelve module implements persistence.

When looking at this chapter and Chapter 12, Storing and Retrieving Objects with SQLite, it becomes clear that mastering object-oriented programming involves some higher-level design patterns. We can't simply design classes in isolation; we need to look at how classes are going to be organized into larger structures. Finally, and most importantly, brute-force search is a terrible thing; it must be avoided.