1 / 27

Re-evolving Design Patterns

Chris Hance. Re-evolving Design Patterns. Why “Re-”evolving?. NIH Epidemic My name is Chris, and I’m a… VB6 Coder YAGNI. Who Are You?. A Drag-n-drop Developer A Design Patterns Practitioner Somewhere In Between The Heckling Section Making A Quick Exit. What Do I Know?.

tegan
Download Presentation

Re-evolving Design Patterns

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Chris Hance Re-evolving Design Patterns

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

  3. Who Are You? • A Drag-n-drop Developer • A Design Patterns Practitioner • Somewhere In Between • The Heckling Section • 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”

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

  8. 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 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 RootsEric 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

  18. 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. Do you want to separate instantiation and reference setting code from data access? Factory vs DAL?

More Related