1. Architecture Patterns Design Patterns
Architectures 2
Architecture Patterns
Design Patterns

2. Layer Supertype
Some functionality is frequently common for all classes
In a module or layer
Separated out in a ”layer supertype”
Domain layer
Data mapper ”layer”

3. Testing and Speed Considerations
Not all tests need real DB
Some test domain
Some test mapper
Some test DB access
When focus is not db
A fake db will do
Replace data mapper with one using in-memory data
Mappers need same interface
Apply DIP
Request
Data Mapper
Presentation Logic
Use
Create/Read
Object-oriented Domain Model
Access
Data Source Logic

4. What We Have We have two setups with mapper classes
Each with its own layer supertype

5. What we Need
The mappers should be interchangeable, so we need something like this
The DB client should not bother whether it gets a Linq, SQL or Dummy
The RoomMapper interface needs to be the same
The client depends on an interface, not on a particular mapper
DIP with dynamic replacement of the actual mapper possible

6. Arrange Mappers According to Domain Classes
What the client is concerned about
To get a room mapper, a person mapper, a booking mapper
Not interested in whether it is linq, sql or dummy
Need an orthogonal structure
One mapper from each technology need to implement RoomMapper, PersonMapper etc
ISP: Treat classes according to their roles (interfaces)

7. Where the Mapper Comes From
The client can get its mapper in two different ways
Have it given to itself from the outside: Dependency Injection
Ask someone for it
We may let it ask for it
Depending on setups, we may want to have different setups
LinqBookingMapper, LinqRoomMapper, LinqPersonMapper
DummyBookingMapper, DummyRoomMapper, DummyPersonMapper
But not
LinqBookingMapper, DummyRoomMapper, SqlPersonMapper
The setup needs to be consistent

8. Solution: Abstract Factory
Use design pattern Abstract Factory
One factory delivers a consistent set of mappers

9. Applying Patterns Refactoring Architecture Patterns Design Patterns
Singleton
Abstract Factory
XP: eXtreme Programming, Kent Beck et al
DSDM: Dynamic System Development Method, DSDM Consortium, UK
Crystal: Crystal Clear and other Crystal methods by Alistair Cockburn
Evo: Evolutionary development, Tom Gilb
FDD: Feature Driven Development, Jeff De Luca
Lean: Lean Software Development, Mary and Tom Poppendieck 9

10. Where The Factory Comes From: Singleton
With different factories, one is the current one
Assign that one to a singleton
Similar to a global variable
MapperFactory.Instance returns the current factory
Every time you need a new room mapper
roomMapper = MapperFactory.Instance.MakeRoomMapper();
The factory singleton manages a current instance in terms of MapperFactory
That is an abstract class
We need to inject an instance of a concrete class into the singleton
MapperFactory.SetFactory(new LinqMapperFactory());

11. The Singleton namespace DataMappers {
abstract public class MapperFactory
private static MapperFactory instance;
public static void SetFactory(MapperFactory factory)
instance = factory; }
public static MapperFactory Instance
get { return instance; }
abstract public RoomMapper MakeRoomMapper();
abstract public PersonMapper MakePersonMapper();
abstract public BookingMapper MakeBookingMapper();

12. Subclasses Implement the Factory Methods
using DataMappers;
namespace LinqDataMappers {
public class LinqMapperFactory : MapperFactory
public override RoomMapper MakeRoomMapper()
return new LinqRoomMapper(); }
public override PersonMapper MakePersonMapper()
return new LinqPersonMapper();
public override BookingMapper MakeBookingMapper()
return new LinqBookingMapper();

13. The Factory Hierarchy The Instance is typed MapperFactory
So it may return any of the subclasses
It needs to be instantiated
See demo
Principle: LSP
The clients will not notice any difference

14. The Complete Mapper Solution…

15. Using the Mappers
Now we know how to create and manage mappers in a consistent way
Through an Abstract Factory
The application still needs to get hold of a mapper to read and save data
The abstract superclass Mapper may act as a mapper holder
A Singleton-like property for each mapper
Mapper.BookingMapper.GetAll()
A method to clear the current mapper of each kind
Called at the end of a user transaction
Needed in order to reset the Identity Map
Which is needed to avoid duplicate in-memory objects
Mapper.ClearBookingMapper()
A method to clear all the current mappers
Mapper.ClearMappers()

16. Implementing the Mapper Access Mechanisms
A singleton-like static accessor property in abstract class Mapper
private static BookingMapper bookingMapper;
public static BookingMapper BookingMapper { get { if (bookingMapper == null) bookingMapper = MapperFactory.Instance.MakeBookingMapper(); return bookingMapper; } }
Resetting a mapper
public static void ClearBookingMapper() {bookingMapper = null;}
Resetting all the mappers
public static void ClearMappers() {ClearRoomMapper(); ClearPersonMapper(); ClearBookingMapper();}

17. Consequences of Mapper and Identity Map
Clients may use the BookingMapper etc properties directly
Mapper.BookingMapper always gives a (new or old) booking mapper
Call ClearMappers() when done with a user transaction
That is after the last update of the user transaction
Or when starting a new one with fresh data
When you know that you are done with your domain objects
Resets the identity map in the mapper
Assures that reading the same record several times does not result in several copies of the corresponding domain object in memory
Triggers fresh reading from the database on the next read operation
In case some other user has made any changes

18. Complete Example: Menu Selection ”Display All”
Reloading all the bookings
private void allToolStripMenuItem_Click(object sender, EventArgs e) { LoadData(); }
private void LoadData() { Mapper.ClearBookingMapper(); Display(Mapper.BookingMapper.GetAll()); }
private void Display(IList<Booking> list) { bookingBindingSource.DataSource = from item in list orderby item.Venue.Name ascending, item.FromTime ascending select item; }