Hi,
This blog post summarizes the overview of LINQ.
Below are the new features been introduced in Orcas
§ Automatic Properties
§ Object Initializers
§ Collection Initializers
§ Extesnion Methods
§ Lambda Expressions - p => expressions
§ Query Syntax
§ Anonymous Types
§ Var Keyword
These language features help in making query against relational data. This overall querying programming model is called as "LINQ" - which stands for .NET Language Integrated Query.
LINQ Features list:
· LINQ can be used with any data source.
· LINQ can express efficient query behavior in many programming language of choice.
· LINQ can optionally Transform/Shape data query results into whatever format you want, and then easily manipulate the results.
· LINQ-enabled languages can provide Full Type-Safety And Compile-Time Checking of query expressions.
· LINQ-enabled development tools can provide full intellisense, debugging, and rich refactoring support when writing LINQ code.
· LINQ supports a very rich extensibility model that facilitates the creation of very efficient domain-specific operators for data sources.
· The "Orcas" version of the .NET Framework ships with built-in libraries that enable LINQ support against Objects, XML, and Databases.
LINQ to SQL
· It is an O/RM (object relational mapping) implementation that ships in the .NET Framework "Orcas" release, and allows us to MODEL A RELATIONAL DATABASE USING .NET CLASSES.
· These classes are typically referred to as "Entity Classes" and instances of them are called "Entities". Entity classes map to tables within a database. The properties of entity classes typically map to the table's columns. Each instance of an entity class then represents a row within the database table.
· We can then query/ update/insert/delete the database using LINQ.
· It fully supports transactions, views, and stored procedures.
· It also provides an easy way to integrate data validation and business logic rules into your data model.
· "Orcas" ships with a LINQ to SQL designer (.dbml) that provides an easy way to model and visualize a database as a LINQ to SQL object model.
· This designer has two parts. The Let Part (Broader one) contains Tables and the right part (Narrow one) contains SP, Functions.
DataContext Class
· For each LINQ to SQL designer file added to our solution, a custom DataContext class will also be generated.
· This DataContext class is the main conduit by which the entities (Entity Classes) from the DB are queried and as well as apply changes.
· The DataContext class created will have properties that represent each Table we modeled within the database, as well as methods for each Stored Procedure we added.
Entity Classes
· Do not have to derive from a specific base class.
· All classes created using the LINQ to SQL designer are defined as "partial classes" - which means that you can optionally drop into code and add additional properties, methods and events to them.
· Unlike the DataSet/TableAdapter feature provided in VS 2005, when using the LINQ to SQL designer you do not have to specify the SQL queries to use when creating your data model and access layer. Instead, you focus on defining your entity classes, how they map to/from the database, and the relationships between them. The LINQ to SQL OR/M implementation will then take care of generating the appropriate SQL execution logic for you at runtime when you interact and use the data entities. You can use LINQ query syntax to expressively indicate how to query your data model in a strongly typed way.
Naming and Pluralization
· To notice LINQ to SQL designer automatically "pluralizes" the various table and column names when it creates entity classes based on your database schema.
· i.e. The "Products" table resulted in a "Product" class, and the "Categories" table resulted in a "Category" class. This class naming helps make our models consistent with the .NET naming conventions.
· We can change the name of a class or property that the designer generates. This ability to have entity/property/association names be different from your database schema ends up being Very Useful in a number of cases. In particular:
· When your backend database table/column schema names change. Because your entity models can have different names from the backend schema, you can decide to just update your mapping rules and not update your application or query code to use the new table/column name.
· When you have database schema names that aren't very "clean". For example, rather than use "au_lname" and "au_fname" for the property names on an entity class, you can just name them to "LastName" and "FirstName" on your entity class and develop against that instead (without having to rename the column names in the database).
Relationship Associations
· When you drag objects from the server explorer onto the LINQ to SQL designer, Visual Studio will inspect the primary key/foreign key relationships of the objects, and based on them Automatically Create default "relationship associations" between the different entity classes it creates.
· If you don't like how the designer has modeled or named an association, you can always override it. Just click on the association arrow within the designer and access its properties via the property grid to rename, delete or modify it.
Reference:
http://weblogs.asp.net/scottgu/archive/2007/05/19/using-linq-to-sql-part-1.aspx
Hope this helps.
Thanks & Regards,
Arun Manglick || Tech Lead
No comments:
Post a Comment