DOMAIN ORIENTED DEVELOPMENT
Rajmund Rzepecki
LA Code Camp III
University of Southern California, LosAngeles
October 24th, ...
I have a Power Point, too bad…
http://www.wittcom.com/index_book.htm
http://www.lifeafterpowerpoint.com/?page_id=178
http:...
Some famous quotes…
 “When nature has work to be done, she
creates a genius to do it. “
RalphWaldo Emerson
 “No great ge...
Overview
 What databases were created for?
 ORM inception
 What is server side ORM anyway?
 Examples
What databases were created for?
 SQL has been designed to operate on data and does it
great!
 Set based paradigm can ov...
ORM inception
 Always table centric, even when utilizes a model it
pollutes it with needed table and column names
 Can’t...
Relational vs. Object
Design concepts
optimized for relational
storage (i.e. redundancy
elimination)
Rich hierarchical str...
What is server side ORM anyway?
 How about ORM in database?
 What can join the two worlds together?
 Can accept entire ...
 Note in case of *all* ORMs out there (including
modern EF) the model lives in the application
 That means no matter how...
 Changes spawned across layers need more time and
increase maintenance costs (i.e. checking out more
files, bothering oth...
Build and deploy process
• Database
structure change
Maintenance
• Update model in
code
No decoupling
• Often fix the
code...
Classic ORM characteristic
Database
Application
code
Entity mapping and
persistence logic
XML ORM characteristic
Database
Application
code
Entity mapping and
persistence logic
Filling the missing piece…
 Use the XML as the magic
glue.
 Leverage built-in
serialization processes.
 Very flexible a...
Data Access Layer
ORM in database (XML mapping)
• Straightforward (no hidden model to
maintain)
• Full control (you write ...
Why abstracting access to the database?
My little
database
own only
by me ?
Reporting
Web
application
Windows
application
...
Why SOA concepts have been invented?
Database
Application
code
Can keep most changes here Can keep most changes here
Abstr...
OK, how do we do that?
• Model entities in XML schema or pull it from existing
tables. Use tools likeVisual Studio or XML ...
XML data type operators
• Extracts value as a given type for certain position..value
• Converts multiple sibling nodes int...
About bad practices…
 When I see stored procedures with 50
parameters something really smells…
 How this can be maintain...
Send/Receive entire entity in
one shot.
Order
Address
Customer
Optimized persistence and retrieval
Model
entities
using
schema
Generate
code from
model
Serialize
and
exchange
entities
Process
and persist
in
database
Ideal...
Model in
UML
Model
entities
using
schema
Generate
code
from
model
Serialize
and
exchange
entities
Process
and
persist in
d...
Object model seen in code
Customer
Address
Free shipping
allowance
Discount rate
Name
Ordering
preferences
Entity reuse diagram using XSD
Order
Address
Shipping
a1:Street
Name
a2:ZIP code
Billing
a1:Street
Name
a1:ZIP code
Order ...
Project timeframe vs. benefit
Beginning of the project
slower due to writing
persistence code in SQL
Good reuse of modeled...
When to use?
Classic
ORM
XML ORM
DB
APP
DAL
BLL
DB
APP
DAL
BLL
Usages of XML with database
 Ordinary data storage (in XML typed column)
 Entity transport and model mapping
 Documenta...
Comparison (my subjective opinion)
 Classic (client) ORM
 Table centric -YTYP -YouTouchYou Pay,You BreakYou Pay
 Genera...
Comparison (my subjective opinion)
 XML (server) ORM
 Much simplified Data Access Layer following some
conventions
 Ful...
Performance myths?
 As with every SQL solution it’sYMMV (Your Mileage MayVary)
 I can’t see a true and reliable comparis...
Questions?
Thank you
for coming
Upcoming SlideShare
Loading in …5
×

Domain oriented development

1,452 views
1,356 views

Published on

When things can't be done in such a way that a small change to the db causes many changes and recompilation of your app is this really agile? Do you really believe it or had sworn to it? I use my own technique to minimize or completety eliminate this common problem. Come to see what you might never heard of.

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,452
On SlideShare
0
From Embeds
0
Number of Embeds
123
Actions
Shares
0
Downloads
0
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • Jezeli Google i Amazon mialoby zawiadamiac wszystkich partnerow o kazdej zmianie w ich bazie danych to co by to bylo?
  • Domain oriented development

    1. 1. DOMAIN ORIENTED DEVELOPMENT Rajmund Rzepecki LA Code Camp III University of Southern California, LosAngeles October 24th, 2010 Reducing impact of database changes in the application Version 1.0
    2. 2. I have a Power Point, too bad… http://www.wittcom.com/index_book.htm http://www.lifeafterpowerpoint.com/?page_id=178 http://blog.indezine.com/2010/10/real-leaders-dont-do-powerpoint.html Chris Witt
    3. 3. Some famous quotes…  “When nature has work to be done, she creates a genius to do it. “ RalphWaldo Emerson  “No great genius has ever existed without some touch of madness. “ Aristotle  “The difference between stupidity and genius is that genius has its limits. “ Albert Einstein
    4. 4. Overview  What databases were created for?  ORM inception  What is server side ORM anyway?  Examples
    5. 5. What databases were created for?  SQL has been designed to operate on data and does it great!  Set based paradigm can oversee data state across many entities at the same time  Why people feel fear of SQL? Laziness?  Does sending all possible kind of queries make sense or data should be exchanged rather?  If one treats the DB as a mere collection of tables and columns why didn’t use Clipper or even text file?  Think why you cared it had to be relational?  Why pay $$$ for licensing when using only storage, but all the features (security, persistence logic)?
    6. 6. ORM inception  Always table centric, even when utilizes a model it pollutes it with needed table and column names  Can’t work without this tight coupling knowledge  Evaluate how changes affect the model and code  Maintenance loop and scope  Must always keep in sync  Need thorough versioning to ensure matching  Does it really need to pull out ID of every parent record inserted just to insert its children?  Most newer ORM out there recycles the older one over and over and we constantly upgrade the code heading nowhere really  Is this really “Agile” practice?Who is fooling who…?
    7. 7. Relational vs. Object Design concepts optimized for relational storage (i.e. redundancy elimination) Rich hierarchical structure and relationships between objects easy to manipulate programmatically
    8. 8. What is server side ORM anyway?  How about ORM in database?  What can join the two worlds together?  Can accept entire object tree and return all of them with all IDs in place.  Stored procedures and views are not there only for performance (maybe over utilized sentence), but primarily for abstraction! (care even more)  Don’t think you’re about to keep business logic in the database. It’s the persistence logic (what goes where), not business logic itself!  Foreign keys and such – it’s not business logic, those are tools to help enforce these.
    9. 9.  Note in case of *all* ORMs out there (including modern EF) the model lives in the application  That means no matter how great and smart it is, it has to live with specific version of the database, too bad…  Even when theoretically the model shields application code from database changes and its internals it can do it up to a certain extent and more complex changes propagation are simply unavoidable  Database structure affects the model (something has to change - either the model or stored procedure, what is better?) ORM abstraction myths?
    10. 10.  Changes spawned across layers need more time and increase maintenance costs (i.e. checking out more files, bothering other team, deployment down time, version synchronization)  Each affected layer need to be tested for compliance again  Better when changes are isolated between layers and stay where these belong as much as possible  Do major online sites (like Amazon,Twitter, Netflix, etc.) ask every developer on the planet to please recompile their application, because they had (re)moved one table they don’t need anymore? ORM abstraction myths?
    11. 11. Build and deploy process • Database structure change Maintenance • Update model in code No decoupling • Often fix the code to work with new model Must be in sync • Recompile, retest and wait for next publish cycle Wasted time By utilizing most classic ORM solutions available today
    12. 12. Classic ORM characteristic Database Application code Entity mapping and persistence logic
    13. 13. XML ORM characteristic Database Application code Entity mapping and persistence logic
    14. 14. Filling the missing piece…  Use the XML as the magic glue.  Leverage built-in serialization processes.  Very flexible and durable in regard to modifications.  Industry standard for over a decade.  Supported by major databases: SQL Server, IBM DB2, Oracle.  Is it a silver bullet?
    15. 15. Data Access Layer ORM in database (XML mapping) • Straightforward (no hidden model to maintain) • Full control (you write the code) • No “outside” knowledge needed ORM in code (LINQ2SQL, NHibernate, Subsonic, etc.) • Model customization learning curve • May be tricky to change existing one • Mapping needs refresh after database changes Entity persistence comparison
    16. 16. Why abstracting access to the database? My little database own only by me ? Reporting Web application Windows application Specialized interfaces BizTalk / SOA layer Department X
    17. 17. Why SOA concepts have been invented? Database Application code Can keep most changes here Can keep most changes here Abstraction barrier Flexible contract as an interface between, but loosely versioned
    18. 18. OK, how do we do that? • Model entities in XML schema or pull it from existing tables. Use tools likeVisual Studio or XML Spy.XSD • Well known part of MS SDK. Generate hierarchical classes (C# orVB).XSD.EXE • Utilize standard processes to represent business objects as XML without getting hands dirty..NET serializer • Translate XML nodes into SQL row set, map attributes and values to columns. Standard SQL operations apply.XQuery
    19. 19. XML data type operators • Extracts value as a given type for certain position..value • Converts multiple sibling nodes into a SQL row set..nodes • Utilizes XQuery language to perform additions, changes and deletions straight within XML data..modify • Similar to native SQL operator, but operates directly on XML nodes..exists
    20. 20. About bad practices…  When I see stored procedures with 50 parameters something really smells…  How this can be maintained?  When I see passing sub entities in a comma delimited strings something really smells…  Wouldn’t be better to pass an entire entity instead of bunch of parameters?  Yes, use XML!
    21. 21. Send/Receive entire entity in one shot. Order Address Customer Optimized persistence and retrieval
    22. 22. Model entities using schema Generate code from model Serialize and exchange entities Process and persist in database Ideal design process
    23. 23. Model in UML Model entities using schema Generate code from model Serialize and exchange entities Process and persist in database Ideal design process
    24. 24. Object model seen in code Customer Address Free shipping allowance Discount rate Name Ordering preferences
    25. 25. Entity reuse diagram using XSD Order Address Shipping a1:Street Name a2:ZIP code Billing a1:Street Name a1:ZIP code Order details c1:Customer a1:Street Name a1:ZIP code p1:Line item p1:Product p1:Quantity Primitive type definitions Types reusing primitives Namespace “a1” may define ZIP code as just 5 digits while “a2” may dictate 9 digits
    26. 26. Project timeframe vs. benefit Beginning of the project slower due to writing persistence code in SQL Good reuse of modeled entities and procedures Greater abstraction helps down the road reducing further maintenance
    27. 27. When to use? Classic ORM XML ORM
    28. 28. DB APP DAL BLL
    29. 29. DB APP DAL BLL
    30. 30. Usages of XML with database  Ordinary data storage (in XML typed column)  Entity transport and model mapping  Documentation of business processes (in schema collections)  Input data validation (intrinsic, no special code)  Audit trail (output changes from triggers, etc.)  Hardcopy for incoming data requests  Ideal for unstructured (temporal) data  Verification for business logic execution (unit test)  MS Office (Open) document storage and processing
    31. 31. Comparison (my subjective opinion)  Classic (client) ORM  Table centric -YTYP -YouTouchYou Pay,You BreakYou Pay  Generated entities often bear framework specific persistence behavior making it not so storage agnostic (e.g. all Subsonic classes do inherit from “Active Record”, EF has a “Context”, can’t reuse straight in Silverlight, so you need another framework on top of it, Data Services)  Complex engine need to generate those “perfect” queries (e.g. expression trees, almost like Artificial Intelligence). Need to be updated for newer SQL standard revisions  No guarantee it will always work correctly, some use SCOPE_IDENTITY, some IDENT_CURRENT  Paging implemented differently across versions, some use ROW_NUMBER, some use recursive methods  Uncontrolled locks may occur  Chatty style of communication (torturing the database)  Is that going in the right direction? (recall LINQ2SQL…)
    32. 32. Comparison (my subjective opinion)  XML (server) ORM  Much simplified Data Access Layer following some conventions  Full abstraction for client code (generate pure DTO/POCO and reuse)  Need to write persistence logic ourselves  Can pull out documentation for database and data flow easily  May reduce performance slightly
    33. 33. Performance myths?  As with every SQL solution it’sYMMV (Your Mileage MayVary)  I can’t see a true and reliable comparison between the two.Too many factors to consider like reading pages more or less randomly, index hits, caches, etc.  Please test for yourself in your environment and for expected volume.  Don’t make arguments like between JSON and SOAP. For the sake of God,THIS serialization and transport doesn’t go through the Internet wire. At most the data travel from your application server to the database and/or back (you do have X times 1 Gb NIC teaming, right?).  Short naming in XML and attribute use can reduce size to equal TDS (Tabular Data Stream). Just override serialization attributes.  Hierarchy itself reuses otherwise redundant IDs.  We have more processing power than 10 years ago.  Storage is cheap those days.
    34. 34. Questions?
    35. 35. Thank you for coming

    ×