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.

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. 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. 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. Overview
 What databases were created for?
 ORM inception
 What is server side ORM anyway?
 Examples

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. 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. 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. 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.  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.  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. 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. Classic ORM characteristic
Database
Application
code
Entity mapping and
persistence logic

13. XML ORM characteristic
Database
Application
code
Entity mapping and
persistence logic

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. 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. 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. 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. 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. 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. 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. Send/Receive entire entity in
one shot.
Order
Address
Customer
Optimized persistence and retrieval

22. Model
entities
using
schema
Generate
code from
model
Serialize
and
exchange
entities
Process
and persist
in
database
Ideal design process

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. Object model seen in code
Customer
Address
Free shipping
allowance
Discount rate
Name
Ordering
preferences

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. 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. When to use?
Classic
ORM
XML ORM

28. DB
APP
DAL
BLL

29. DB
APP
DAL
BLL

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. 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. 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. 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. Questions?

35. Thank you
for coming