Chris Hance. Why “Re-”evolving? NIH Epidemic My name is Chris, and I’m a… VB6 Coder ...
-
Upload
christina-wilson -
Category
Documents
-
view
216 -
download
2
Transcript of Chris Hance. Why “Re-”evolving? NIH Epidemic My name is Chris, and I’m a… VB6 Coder ...
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?