1. Chris Hance

2. Why “Re-”evolving?  NIH Epidemic  My name is Chris, and I’m a… VB6 Coder  YAGNI

3. Who Are You? 1. A Drag-n-drop Developer 2. A Design Patterns Practitioner 3. Somewhere In Between 4. The Heckling Section 5. Making A Quick Exit

4. What Do I Know?  Not as much as I’d like  But way too much VB6 and COM  Definitely Certifiable  MCDBA on SQL 2000  MCPD on.NET 3.5 Windows Apps

5. Where do patterns come from?  Canonical Answer  Design Patterns: Elements of Reusable Object- Oriented Software, “Gang Of Four”  Patterns of Enterprise Application Architecture (PoEAA), Martin Fowler  Real Answer  “Lots of people do it this way.”

6. Lots of People are Wrong  Anti-pattern  Common practice that’s (usually) inefficient or incorrect.  Get used to “It Depends”  www.c2.com/cgi/wiki “Portland Pattern Repository's Wiki” www.c2.com/cgi/wiki

7. Antipatterns? 1. Forms Over Data 2. Stored Procedures for Everything! 3. Naïve OOP  We'll discuss what's wrong and right.

8. 1. Forms Over Data Sub Form_Load SQL = "Select * From " Set RS = Conn.Execute SQL Do Until RS.EOF Grid.AddItem RS(0) & Tab & RS(1) RS.MoveNext Loop End Sub

9. 1.Forms Over Data  No way to share this code  That's what Object-Oriented is for, right?  Coder has to know SQL Schema  Stored procedures?  Data Access Layer (DAL)?  Object/Relational Mapper (O/RM)?

10. 2. Stored Procedures for Everything! Sub Form_Load Set RS = Conn.Execute "prGetMyTable" Do Until RS.EOF Grid.AddItem RS(0) & Tab & RS(1) RS.MoveNext Loop End Sub

11. 2. Stored Procedures for Everything!  Every change requires a DBA and a developer.  DBAs can change the recordset.  Database lock-in?  Some reusability.

12. 3. Naïve OOP  Build an Object Model  Link Everything to Everything  Edit Anything  Commit It All Back?

13. 3. Naïve OOP  Worked fine for Build (Compile) Automation  Very little "Commit It All Back"  Could only model changes, not the whole system, for memory and speed.  Still hard to change.  Can you "load everything" and "save everything" safely?

14. 3. Simplified Build Model

15. 3. Simplified Student Model Not simplified enough.

16. 4. Concentrations  Light version of Aggregate Roots Eric Evans, Domain Driven Design  Limited models for updating data  Top level = what you're updating  Attach child collections / objects  Reference other concentrations

17. 4. Concentrations

19. Where do we get data?  Classes self-populate?  E.g. Student.LoadByID(int ID)  Single Responsibility Principle (SRP) Violation  Unit testing is slow and difficult.  Object/Relational Mapper (ORM)  Another learning curve, but worth it.

20. Where do we get data? (2)  Custom Data Access Layer (DAL)  Talks to the database (or is the collection)  Retrieves editable objects  Save the edited objects  Nothing about keeping them consistent in memory.

21. Command / Query Separation  Don't use your DAL for reports  Don't need to update  Don't need to enforce business rules  Just need properly linked rows or hierarchical data  Data Warehouse or raw SQL

22. Multiple Versions of a DAL  Unit Testing – Mock DAL  Compatibility with multiple DBs  Different implementations for QA / Prod  Probably requires multiple assemblies  Single assembly would contain unused code  Define a DAL interface

23. Replaceable DAL

24. Cross-concentration Queries  Should one DAL know about another DAL?  CheckOutDAL references ContactDAL?  If not, returned objects are incomplete  If so, do we ever want to "short-circuit" and populate the references locally?  Teacher name & room number on Checkout list by date

25. Cross-DAL references

26. Abstract Factory Pattern  Different factories create objects differently, and/or instantiate different classes of the same interface.  Factories are interchangeable (like the previous DALs).  Domain Objects have different behavior or implementation, same interface.

27. Factory vs DAL?  Do you want to separate instantiation and reference setting code from data access?