Object Relational Mapping with LINQ To SQL
Download as PPT, PDF0 likes1,595 views
The document discusses the challenges of impedance mismatch between relational databases and object-oriented systems, highlighting issues such as differing type systems, architectural styles, and identity constructs. It also introduces Object Relational Mapping (ORM), a technique that facilitates integration between incompatible type systems, and explains how LINQ (Language Integrated Query) can provide seamless data access with a strong relationship to domain models. Finally, it outlines scenarios where LINQ to SQL is an effective choice for applications needing quick development cycles with a straightforward one-to-one mapping between objects and relational databases.
Object Relational Mapping with LINQ To SQL
- 2. OR Impedance Mismatch •Conflicting type systems •Conflicting design goals Database system focuses specifically on the storage and retrieval of data, whereas an object system focuses specifically on the union of state and behavior for easier programmer manipulation •Conflicting architectural style Most database products are built to assume a fundamentally client/server style of interaction, assuming the database is located elsewhere on the network, and programs accessing the database will be doing so via some sort of remote access protocol. Object systems assume the precise opposite, and in fact, perform significantly worse when distributed. •Differing structural relationships Relational data stores track entities in terms of relations between tuples and tuplesets; object-oriented systems instead prefer to track entities in terms of classes, compilation of state and behavior that relates to one another through IS-A and/or HAS-A style unidirectional connections. Where databases use foreign-key relationships to indicate relations, objects use references or pointers 2
- 3. OR Impedance Mismatch •Differing identity constructs Object systems use an implicit sense of identity to distinguish between objects of similar state (the ubiquitous this pointer or reference), yet databases require that sense of identity to be explicit via primary key column or columns. In fact, in modern object-oriented languages an object system cannot be built without a sense of object identity, whereas relational tables can have no primary key whatsoever, if desired. •Transactional boundaries Object systems do not have any sense of "transactional demarcation" when working with the objects, whereas database instances must in order to deal with the multi-user requirements of a modern . client/server-based system •Query/access capabilities Retrieving data stored in a relational database makes use of SQL, a declarative language predicated on the mathematical theory of relational algebra and predicate. In object systems, the entire object is required in order to navigate from one object to the next, meaning that the entire graph of objects is necessary in order to find two disparate parts of data—for a system intended to remain entirely in working memory, this is of no concern, but for a system whose principal access is intended to be distributed, as relational database are, this can be a crippling problem. 3
- 4. Object Relational Mapping Wikipedia defines an ORM as: “a programming technique for converting data between incompatible type systems in relational databases and object-oriented programming languages. This creates, in effect, a "virtual object database," which can be used from within the programming language.” An ORM has to provide a facility to map database tables to domain objects, using a design surface or wizard. This mapping is in-between your database and domain model, independent from the source code and the database. The ORM runtime then converts the commands issued by the domain model against the mapping into back end database retrieval and SQL statements. Mapping allows an application to deal seamlessly with several different database models, or even databases. 4
- 5. The LINQ Project C# VB Others… .NET Language Integrated Query Standard DLinq XLinq Query (ADO.NET) (System.Xml) Operators <book> <title/> <author/> <year/> <price/> </book> Objects SQL WinFS XML
- 6. Data Access In APIs Today Sql C onnect i on c = new Queries in Sql C onnect i on( …) ; quotes c. Open( ) ; Sql C m om and cm = new Sql C m d om and( Arguments @ SELEC c. N e, c. Phone " T am loosely FR M C O ust om s cer bound W ER c. C t y = @ H E i p0" Results ); loosely cm Par am er s. AddW t hVal ue( " @po" , d. et i typed Compiler " London" ) ; at eader dr = c. Execut e( cm ; cannot help D aR d) w l e ( dr . R hi ead( ) ) { catch st r i ng nam = dr . G St r i ng( 0) mistakes e et ;
- 7. Data Access with DLINQ publ i c cl ass C ust omer Classes { describe publ i c i nt I d; data Tables are publ i c st r i ng N e; am collections publ i c st r i ng Phone; … } Query is Tabl e<C ust om > cust om s = er er natural part db. Cust om s; er of the language The var cont act s = compiler f r om c i n cust om s er helps you
- 8. DLinq For Relational Data Accessing data with DLinq Classes public class Customer { … } describe data public class Northwind: DataContext Tables are { like collections public Table<Customer> Customers; … Strongly typed Northwind db = new } Northwind(…connection ); var contacts = Integrated from c in db.Customersquery syntax where c.City == "London" select new { c.Name, c.Phone }; typed Strongly results
- 9. Architecture f r om c i n db. Cust om s er w e c. C t y == " London" her i Application sel ect new { c. N e, c. Phone } am LINQ Query Objects SubmitChanges() Services: DLinq - Change tracking - Concurrency control (ADO.NET) - Object identity SQL Query Rows SQL or Stored Procs sel ect N e, Phone am f r om cust om s er w e ci t y = ' London' her SQLSer
- 10. Key Takeaways Language integrated data access Maps tables and rows to classes and objects Builds on ADO.NET and .NET Transactions Mapping Encoded in attributes Relationships map to properties Manually authored or tool generated Persistence Automatic change tracking Updates through SQL or stored procedures DataContext Strongly typed database
- 12. Key Takeaways Language Integrated Query Compile-time type checking, IntelliSense SQL-like query syntax With support for hierarchy and relationships Intelligent object loading Deferred or immediate 12
- 13. Updating Objects
- 14. Key Takeaways Auto-generated updates Using optimistic concurrency Transactions Integrates with System.Transactions SQL pass-through Returning objects from SQL queries 14
- 15. DLinq Summary Allows access to relational data as objects Supports Language Integrated Query Works with existing infrastructure Unifies programming model for objects, relational and XML 15
- 16. When to Use LINQ to SQL? The primary scenario for using LINQ to SQL is when building applications with a rapid development cycle and a simple one-to-one object to relational mapping against the Microsoft SQL Server family of databases. In other words, when building an application whose object model is structured very similarly to the existing database structure, or when a database for the application does not yet exist and there is no predisposition against creating a database schema that mirrors the object model 16
- 17. When to Use LINQ to SQL? I want to… LINQ to SQL is applicable Use an ORM solution and my database is 1:1 with my object model Use an ORM solution with inheritance hierarchies that are stored in a single table Use my own plain CLR classes instead of using generated classes or deriving from a base class or implementing an interface Leverage LINQ as the way I write queries Use an ORM but I want something that is very performant and where I can optimize performance through stored procedures and compiled queries 17