Concepts Flashcards
General concepts shown on part I of the book
What are 4 ways of storing session data on the client side?
- encoding data in a URL
- using cookies
- serializing data into a hidden HTML field
- holding data in objects on a rich client
What are 3 ways of storing session data on the server side?
- as serialized object on the file system
- as serialized object on a key value database
- as broken up data into the database
What are the main problems with storing session data on the client side?
- requires transferring to much data to the server
- data security
- data integrity
Remote interfaces/objects should have […] grained interfaces, while local interfaces/objects should have […] grained interfaces.
- Coarse
2. Fine
What are the pros and cons of using a Domain Model pattern on the Domain Layer?
Pros
- can be used to model complex domain logic
- scales from simple logic to complex
Cons
- hard to to it right
- impedance mismatch with relational databases
What are the the application layer discussed by Fowler?
- presentation
- domain
- data source
What is the most common way of organizing Transaction Scripts
To have several transaction scripts in a single class, where each class defines a subjects area of related scripts.
Which GOF pattern can be used to organize transaction scripts?
The Command Pattern, where each transaction script is coded in its own class.
Why Fowler uses the term Transaction Script?
Because MOST of the time you’ll have a transaction script for each DB transaction.
What does Fowler consider a Simple Domain Model and a Rich Domain Model?
A simple domain model looks very much similar to the database model (one object per DB table).
A rich domain model can be different from the DB model, and uses more OO techniques, and patterns. It is more suited for complex domain logics.
For persistence, a simple domain model can use (…), whereas a rich domain model requires a (…)
Active Record
Data Mapper
Why is it recommended that the Domain Model have a minimum coupling with other layers of the system?
Because business logic can change a lot.
So we should try to make it as easy as possible to modify, test and build that layer.
Bloated Domain Objects are a concern with domain model. Sometimes to avoid bloating, people tend to create usage-specific class (like a transaction script for a specific use case). What is Fowler advice on that?
He says that creating usage specific class can make it harder to see all the logic related to a specific domain object (ex. Order), and because of that duplication of code can occur. Also, bloating happens much less frequently than people usually expect. So it is better to put the logic on the domain object that is seems fit. Bloating will be easy to spot and refactor later.
When using Domain Model, what is the recommended pattern for database interaction?
Data Mapper
What is the main difference between Domain Model and Table Module?
Table Module tends to model classes based on the structure of the database. Table Module objects does not have the notion of identity. While in Domain Model you have one object per instance of domain concept (ex: a specific Order), in Table Module you have one object or class that handles all instances of a domain concept.
