Chris Hance

Why “Re-”evolving?

NIH Epidemic My name is Chris, and I’m a… VB6

Coder YAGNI

Who Are You?

1. A Drag-n-drop Developer2. A Design Patterns Practitioner3. Somewhere In Between4. The Heckling Section5. Making A Quick Exit

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

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.”

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”

Antipatterns?

1. Forms Over Data2. Stored Procedures for Everything!3. Naïve OOP

We'll discuss what's wrong and right.

1. Forms Over Data

Sub Form_Load SQL = "Select * From <table>" Set RS = Conn.Execute SQL Do Until RS.EOF Grid.AddItem RS(0) & Tab & RS(1) RS.MoveNext LoopEnd Sub

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)?

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 LoopEnd Sub

2. Stored Procedures for Everything! Every change requires a DBA and a

developer. DBAs can change the recordset. Database lock-in?

Some reusability.

3. Naïve OOP

Build an Object Model Link Everything to Everything Edit Anything Commit It All Back?

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?

3. Simplified Build Model

3. Simplified Student Model

Not simplified enough.

4. Concentrations

Light version of Aggregate RootsEric Evans, Domain Driven Design

Limited models for updating data

Top level = what you're updating Attach child collections / objects Reference other concentrations

4. Concentrations

4. Concentrations

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.

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.

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

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

Replaceable DAL

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

Cross-DAL references

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.

Factory vs DAL?

Do you want to separate instantiation and reference setting code from data access?