Presentation is loading. Please wait.

Presentation is loading. Please wait.

Object Relational Mapping John M. Miller Perpetual Data Systems.

Similar presentations

Presentation on theme: "Object Relational Mapping John M. Miller Perpetual Data Systems."— Presentation transcript:

1 Object Relational Mapping John M. Miller Perpetual Data Systems

2 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

3 Overview  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 architectures?  Which comes first the data chicken or object egg?

4 What is Object Relational Mapping  Something that persists objects into relational databases  Can be  a software layer using dynamic SQL generation  a method of generating static SQL  Implicit with Domain object models  DataSets need not apply

5  Why are domain models important?  Because Why is OR Mapping Important? I said so  They abstract the data access code hiding the database details  They encapsulate the database in an interface that more closely matches the conceptual domain.  Object Models are more expressive for certain kinds of object interactions  Constraints become easier to implement  Object notation is a natural way of navigating a join path ACustomer.Orders[Number=1001].Items[Item=33].Product.Price  Constraints become easier to implement If AProduct.OnHand < AItem.Quantity Then raise BizRuleXceptn

6 Mappers  Domain models put the responsibility of reconciling design differences between the object and data models on the persistence layer  Persistence Layers  Static  Hand coded  Generated  Dynamic

7 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

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

9 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 modeling  Different Optimizations  Identification schemes are a problem

10 The Impedance Mismatch  Cultural  Created by different camps  Software Architects  The equally dread Database Administrator  Night & Day, Oil & Water, Pickles & Ketchup

11 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?

12 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

13 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

14 So why did Microsoft back away?  To the net effect of leaving the market without a Microsoft OR Mapper until? 2008? 2008?2009?2010?  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?

15 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

16 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

17 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 appears  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

18 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

19 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

20 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 me?  Fidelity Loss

21 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

22 What next?  2/1/2005 - San Diego.NET Developer Group Meeting  Implementing.NET Applications using Conceptual Models

23 Thank You!        

Download ppt "Object Relational Mapping John M. Miller Perpetual Data Systems."

Similar presentations

Ads by Google