you can find several descriptions of Language Integrated Query (LINQ), such as these:
LINQ is a uniform programming model for any kind of data. LINQ enables you to query and manipulate data with a consistent model that is independent from data sources.
LINQ is just another tool for embedding SQL queries into code.
LINQ is yet another data abstraction layer.
All of these descriptions are somewhat correct, but they each focus on just a single aspect. LINQ can do a lot more than just embed SQL queries, it is much easier to use than a “uniform programming model,” and it is far from being just another set of rules for modeling data.
LINQ is a methodology that simplifies and unifies the implementation of any kind of data access. LINQ does not force you to use a specific architecture; it facilitates the implementation of several existing architectures for accessing data. As with every tool, it can be used in both good and in bad ways. To get the most out of LINQ, you will have to master it.
Today, data managed by a program can belong to different data domains: an array, an object graph, an XML document, a database, a text file, a registry key, an e-mail message, Simple Object Access Protocol (SOAP) message content, a Microsoft Office Excel file…. The list is long.
Each data domain has its own specific access model. When you have to query a database, you typically use SQL. You navigate XML data with Document Object Model (DOM) or XQuery. You iterate an array and build algorithms to navigate an object graph. You use specific application programming interfaces (APIs) to access other data domains, such as an Office Excel file, an e-mail message, or the Microsoft Windows registry. In the end, you have different programming models to access different data sources.
The unification of data access techniques into a single comprehensive model has been tried in many ways. For example, there are Open Database Connectivity (ODBC) providers that allow you to query an Excel file as you would a Windows Management Instrumentation (WMI) repository. However, with this approach you use an SQL-like language to access data represented through a relational model. Sometimes data is naturally represented more effectively in a hierarchical or graphical model instead of a relational one. Moreover, if the data model is not tied to the language, you probably have to manage different type systems. All these differences create an “impedance mismatch” between data and code. LINQ tries to solve these issues, offering a uniform way to access and manage data without forcing the adoption of a “one size fits all” model. LINQ leverages commonalities between the operations in these data models instead of flattening the different structures between them.
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment