.NET Three Examples of Applied Patterns Jimmy Nilsson

Transcription

1 .NET Three Examples of Applied Patterns Jimmy Nilsson

2 About Jimmy Nilsson Primarily a developer, but also a trainer and author Blogs at Author of Applying Domain-Driven Design and Patterns and.net Enterprise Design

3 Agenda Short introduction Problem 1: Location of persistence code Problem 2: Queries against a domain model Problem 3: Maintenance of a state graph Bonus: Non-trivial instantiation

4 What s a pattern? A design pattern has Name Problem (including context) Solution Consequences Nothing but simple, flexible and elegant solutions

5 Why learn about patterns? Very important part of the language for developers/architects

6 When to use patterns? Don t design a new application using all the patterns you can think of Start as simple as possible Introduce patterns as required

7 Problem 1: Location of Persistence code Customer * Order We d like to persist information about customers and orders

8 Solution 1A: Save() etc on the Customer Id Name DoStuff() Save() Find(id):Customer Entities * Order Id DoOtherStuff() Save() Find(id):Order Ouch... Hard to control transactions. And not too true to the Single Responsibility Principle (But Active Record [PoEAA] has definitely got a new life...)

9 Solution 1B: Unit of Work+Identity Map [PoEAA] UnitOfWork Find(1) finder an identity map database +RegisterNew(in object) +RegisterDirty(in object) +RegisterClean(in object) +RegisterDeleted(in object) +Commit() [found not null] found found = Get(1) [found is null] found = select... where id = 1 Ouch... Too much responsibility on the client?

10 Solution 1C: Repository [DDD] selection criteria matching objects Delegate client repository database

11 Pause: Gregg Irwin said this about pattern adoption 1. You use it without being aware that you re using it 2. You hear about it, read up on it, and tinker a bit 3. You learn more and start using it explicitly, if naively 4. You get the fire and evangelize (optional) 5. Something clicks 6. You learn more and apply it less naively and more implicitly 7. Time passes and you see flaws 8. You question the concept (often because you misapplied it) 9. You either forget about it or add knowledge and experience (Repeat steps 5-9 if necessary) 10. You use it without being aware that you are using it

12 Problem 2: Queries against a domain model Customer * Order Send letter to all customers who have a credit limit > 1'' and who have bought from a certain product group the last month

13 Solution 2A: Loop Ouch... A relational database is used, instantiation of all customers and orders in the domain model is too expensive

14 Solution 2B: Query Object [PoEAA] Query 1 * Criteria -_operator -_field -_value Ouch... Too much responsibility on the client?

15 Solution 2C: Repository [DDD] selection criteria matching objects Delegate client repository database Ouch... The repository classes may grow very large. And this isn t taking care of the situation when you d like to check a transient customer

16 Solution 2D: Specification [DDD] Invoice +...() +IsDelinquent() : bool InvoiceDelinquency +Test(in invoice) : bool +...() Invoice

17 Problem 3: Maintenance of state graph

18 Solution 3A: if-statements everywhere Ouch... The description of the graph is very mixed up and spread out

19 Solution 3B: A table based representation of the graph Ouch... Hard to elegantly deal with state specific behavior

20 Solution 3C: State [GoF] Context -_state State +Request() +Handle() _state.handle() ConcreteStateA +Handle() ConcreteStateB +Handle()

21 Bonus: Non-trivial instantiation An order can be instantiated as: New ordinary New reservation New credit order New repetition Fetch stored order

22 Bonus A: new() Ouch... The different constructors aren t expressing purpose

23 Bonus B: Static methods Ouch... The class has two different responsibilities (Even if we factor out the fetching of a stored instance)

24 Bonus C: Factory [DDD] new(parameters) product Create client FACTORY product

25 Conclusion Patterns are great to have in the tool box!

26 References Gamma, Helm, Johnson, Vlissides: Design Patterns [GoF] Evans: Domain-Driven Design [DDD] Fowler: Patterns of Enterprise Application Architecture [PoEAA] Fowler: Refactoring [R] Kerievsky: Refactoring to Patterns [R2P] Nilsson: Applying Domain-Driven Design and Patterns [ADDDP]

27 Remember! Fill in the evaluation form and be a part of making Øredev even better. You will automatically be part of the evening lottery