Your SlideShare is downloading. ×
Domain oriented development
Upcoming SlideShare
Loading in...5

Thanks for flagging this SlideShare!

Oops! An error has occurred.

Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Domain oriented development


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 …

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
  • Be the first to comment

  • Be the first to like this

No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

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

    • 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… 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