Test Driven Development and Auto by fjwuxn


									Object Relational Mapping

        John M. Miller
    Perpetual Data Systems
                John M. Miller

 Independent Software Architect, Designer & Developer
 PDC 2002 Speaker
 Collaborator on adding advanced business rule support
  to a commercial .Net application framework
 Member of a team submitting a response to the OMG
  request for a method for formalizing business rules
 XSLT transformations from ORM conceptual models into
  .NET entity business object implementation
 What is Object Relational Mapping
 Why did Microsoft back away?
 Is OR Mapping dead?
 What if it isn't?
 What does it mean for .NET application
 Which comes first the data chicken or
  object egg?
What is Object Relational Mapping
 Something that persists objects into
  relational databases
 Can be
   a software layer using dynamic SQL
   a method of generating static SQL
 Implicit with Domain object models
   DataSets need not apply
Why is OR Mapping Important?
 Why are domain models important?
   Because I said so
      They abstract the data access code hiding the database
      They encapsulate the database in an interface that more
       closely matches the conceptual domain.
          Object Models are more expressive for certain kinds of object
               Constraints become easier to implement
          Object notation is a natural way of navigating a join path
          Constraints become easier to implement
             If AProduct.OnHand < AItem.Quantity Then raise BizRuleXceptn
 Domain models put the responsibility of
  reconciling design differences between the
  object and data models on the persistence
 Persistence Layers
   Static
      Hand coded
      Generated
   Dynamic
          Problems with OR Mapping
   A weakness in the mapper limits the
      capability of the object model and in turn
      the capability of the application
     No standard object query language
     It can’t be done, not practical, a waste of
      time, etc.
     It costs time and money
     The dread impedance mismatch
Wikipedia, C2
    The Impedance Mismatch

"When you notice that you're experiencing
  considerable pain, and you recognize that a
  substantial amount of the pain occurs in and
  around the interface between your code and the
  relational database, then you've found the
  Object/Relational Impedance Mismatch."
    The Impedance Mismatch
 Technical
   Object Modeling and Data Modeling model
    fundamentally different things
      Objects = Process
        Data persistence is secondary
     Data = Structure
        What about static class diagrams?
           Fundamentally flawed for complex structural
     Different Optimizations
     Identification schemes are a problem
    The Impedance Mismatch
 Cultural
   Created by different camps
      Software Architects
      The equally dread Database Administrator
      Night & Day, Oil & Water, Pickles & Ketchup
    The Impedance Mismatch
 Reality
   Neither domain models nor relational
    databases are going away.
   Mappers are the price we pay for playing
   Does it really exist?
 So why did Microsoft back away?
 ObjectSpaces
   Billed as the Microsoft OR Mapper
   Due to ship with Visual Studio 2005
   Rolled into WinFS
      Because
        Overlapped with some of the WinFS persistence story
        Different APIs and Microsoft wanted to unify the APIs
        Microsoft didn’t want to publish ObjectSpaces and then
         release an incompatible WinFS
 So why did Microsoft back away?
 WinFS
   Windows object store
   Due to ship with Longhorn
   Pushed back until after Longhorn
      Because
        It wasn’t going to be ready in time
        Object Persistence is harder than they thought
     E12
 So why did Microsoft back away?
 To the net effect of leaving the market
 without a Microsoft OR Mapper until?
   After first creating a buzz with the initial
    previews of ObjectSpaces and generating
    significant market momentum
 Leaving the development world to wonder
   Is OR Mapping dead?
        Is OR Mapping Dead?
 In the Microsoft community
   Almost
      There are several implementations that were
       available before ObjectSpaces that are still around
      And a few created since
         One that emulates the ObjectSpaces preview API
 In the Java community
   Not even close
      Widely adopted
      Not if, but which one
              What if it isn't?
 You could miss out on a technology that could
  make an application easier to design, implement
  and maintain
 What is the .NET OR faithful to do?
   Wait for Microsoft
   Adopt an existing .NET OR Mapper until Microsoft
    does something
      Try WORM
   Adopt an existing .NET OR Mapper permanently
      nHibernate is hot right now
   Switch to Java
      Like you, they get OR mappers
       What does it mean for .NET
        application architectures?
 XML and DataSets will continue to rule the DAL
    world until a dominate OR mapper for .NET
   OR Mapping will continue to be used sparingly
    and grow as the mappers mature
   Adoption rate in the .NET community should
    mimic the adoption rate for OR mappers in the
    Java community, but at faster pace
   Should be widely adopted in the .NET
    community in 3-4 years
   Hold your breath when WinFS ships
Which comes first the data chicken or object egg?

 Lets say you are starting a new project with:
     Complex business logic
     Complex data relationships
     Interested in creating a domain model and and
      relational database.
 What do you do first?
  1. Call me
  2. Create the object model you want to persist
  3. Create the data model that you know you need
 If you do either 2 or 3 you have to deal with the
   dread impedance mismatch
            The Object Egg
 You create the domain object model first
  using standard OOA&D methods
 Then derive the data structure from the
  object model
 Problems
   Number of tables
   Normalization
   Fragile Structures
          The Data Chicken
 You create the data model first using
  standard data modeling methods
 The derive the domain model from the
  data model
 Problems
    You tell Loss
     Fidelity me?
                  What then?
 Conceptual Models
   Design the structures conceptually first using a formal
    conceptual modeling method
   Derive both the entity object model and data model
    from the conceptual model
 Problems
   Your domain object model needs to collaborate with
    the entity objects
   No standards
   Complex transformation
              What next?
 2/1/2005 - San Diego .NET Developer
 Group Meeting
   Implementing .NET Applications using
    Conceptual Models
                   Thank You!
 jMiller@pdata.com
 pdata.com/jMM
   shrinkster.com/3bt
   en.wikipedia.org/wiki/Object-relational_mapping
   c2.com/cgi/wiki?ObjectRelationalMapping
   theserverside.com/books/review/HibernateReview.tss
   devx.com/vb2themax/Article/19894
 sddotnetdg.org/Events/SDDOTNET+Meetings/default.aspx

To top