Многие воспринимают LINQ to SQL как очередной O/R mapper, но реализованный Microsoft. Учитывая, что от Microsoft всегда ожидают намного большего, чем от более бедных компаний, и тем более от Open Source-разработчиков, у многих при первом знакомстве с LINQ to SQL наступает серьезное разочарование. Однако это разочарование вызвано неправильным пониманием сути используемого в LINQ to SQL подхода. Дело в том, что LINQ to SQL не является O/R mapper-ом. На самом деле LINQ – это абстрактное средство обработки списков, а отдельные разновидности LINQ, такие как LINQ to SQL или LINQ to XML, просто рассматривают некий источник данных как набор списков. Задача средств отображения, присутствующих, например, в LINQ to SQL, не в том, чтобы создать объектную модель, позволяющую скрыть детали БД и обеспечить эффективную обработку данных императивными средствами (в основном фильтрацию списков в циклах), а в том, чтобы ввести в программу некий набор классов, предназначенных для считывания в них данных из таблиц СУБД. При этом LINQ to SQL хотя и позволяет работать с такими классами императивными средствами, но заранее предупреждает, что это будет неэффективно и неудобно. Вместо этого LINQ to SQL предлагает использовать статически типизируемые, проверяемые во время компиляции, SQL-подобные запросы. Эти запросы транслируется в эффективный SQL, который выполняется СУБД. Результаты выполнения этих запросов преобразуются в списки типизированных объектов, которые удобно обрабатывать в таких объектно-ориентированных языках программирования, как VB и C#. Простой пример: предположим, у нас таблица покупателей (Customer), ссылающаяся на список заказов (у каждого покупателя может быть 0 или более заказов, Order), при этом в каждом заказе может быть 0 или более позиций (OrderDetail), и в наши задачи входит посчитать, сколько конкретному покупателю было продано единиц некоторого товара. Предположим, что идентификатор покупателя – ТКС, а идентификатор товара – БумагаА4. И классический O/R mapper, и LINQ to SQL при создании объектной модели для связи между таблицами генерируют соответствующие коллекции. Для нашего примера в классе Customer будет создана коллекция Orders, содержащая список объектов типа Order, а Order будет содержать коллекцию типа OrderDetails, содержащую, соответственно, список позиций заказов (объектов OrderDetail). При использовании традиционного O/R mapper-а было бы совершенно нормально написать код, который получает (с помощью некоторой хитрой функции Lookup) объект по его идентификатору, а дальше, с помощью двух вложенных циклов, пробегает по его коллекции, отбирая нужные элементы. Казалось бы, объем данных невелик (сколько может быть заказов у одного покупателя?), и перебор должен произойти практически мгновенно. Нужную позицию можно отфильтровать с помощью if. Однако ни O/R mapper, ни, тем более, СУБД не знают о наших замечательных намерениях и, если они не используют специальных техник, это приведет к тому, что для выборки каждого объекта будет выполнено отдельное обращение к БД. Конечно, хороший O/R mapper буквально напичкан специальными техниками, сглаживающими подобные неприятности (в частности, они могут выполнять опережающее чтение). Однако без тотального кэширования данных движком O/R mapper и, фактически, дублирования функций СУБД высокой производительности добиться не удастся. Поскольку серьезные БД в память априори не помещаются (тем более в объектном представлении), производительность всех без исключения O/R mapper-ов оставляет желать лучшего. Обратите внимание – это проблема системного характера, и решить ее принципиально, используя данный подход, невозможно. Как же быть? Более 20 лет назад производители СУБД (а именно IBM) решили эту проблему для своих продуктов. Решением был переход от навигационной системы к запросной с использованием языка запросов SQL. SQL в декларативной манере говорит СУБД, какие данные нужны клиенту, что потенциально позволяет СУБД построить эффективный план запроса и возвратить клиенту только требуемые данные. При этом экономятся как ресурсы сервера, так и трафик. Так вот, хотя LINQ to SQL и содержит набор возможностей, похожих на предоставляемые O/R mapper-ами вроде Hybernate, основным средством доступа к данным в нем является SQL-подобный язык запросов. LINQ же обеспечивает его безопасность, проверку ошибок на стадии компиляции, а поддержка Intellisense для запросов, встроенных в язык, появившаяся в VS 2008, существенно повышает производительность программирования. Именно так и нужно смотреть на LINQ, а что касается O/R mapper-а от Microsoft, он, по всей видимости, вскоре появится под названием LINQ to Entity, но, скорее всего, и эта реализация будет склонять программиста к использованию интегрированного языка запросов, а не императивного доступа к данным.

Это абстрактное средство обработки списков

Задача средств отображения, присутствующих, например, в LINQ to SQL, не в том, чтобы создать объектную модель, позволяющую скрыть детали БД и обеспечить эффективную обработку данных императивными средствами (в основном фильтрацию списков в циклах), а в том, чтобы ввести в программу некий набор классов, предназначенных для считывания в них данных из таблиц СУБД.

    static void Main(string[] args)
    {
        NorthwindDataContext db = new NorthwindDataContext();
        var customers = from c in db.Customers select c;
        foreach (var cust in customers)
        {
            Console.WriteLine("Customer {0} ID = {1}", cust.ContactName, cust.CustomerID);
            foreach (var order in cust.Orders)
            {
                Console.WriteLine(" Order Date = {0}", order.OrderDate);
                foreach (var orderDetail in order.Order_Details)
                {
                    Console.WriteLine("    Product {0} Quantity = {1}", orderDetail.Product.ProductName, orderDetail.Quantity);
                }
            }
            Console.WriteLine();
        }
        Console.ReadKey();
    }

G>    static void Main(string[] args)
G>    {
G>        NorthwindDataContext db = new NorthwindDataContext();
G>        var customers = from c in db.Customers select c;
G>        foreach (var cust in customers)
G>        {
G>            Console.WriteLine("Customer {0} ID = {1}", cust.ContactName, cust.CustomerID);
G>            foreach (var order in cust.Orders)
G>            {
G>                Console.WriteLine(" Order Date = {0}", order.OrderDate);
G>                foreach (var orderDetail in order.Order_Details)
G>                {
G>                    Console.WriteLine("    Product {0} Quantity = {1}", orderDetail.Product.ProductName, orderDetail.Quantity);
G>                }
G>            }
G>            Console.WriteLine();
G>        }
G>        Console.ReadKey();
G>    }
G>

var customers = from c in db.Customers select c;

    public class C1
    {
        public C1(int a)
        { A=a; }

        public int A { get; set; }
    }

var customers = from c in db.Customers select c;

foreach (var order in cust.Orders)

var _orders = from o in db.Orders select o;

public abstract class ACustomers{
// описать привязку полям к членам
}
List<ACustomers> customers ;
using (DbManager db = new DbManager())
{
  customers = db
    .SetCommand("SELECT Id, Name, ... FROM customers")// или SetSpCommand("GetCustomers")
    .ExecuteList<ACustomers>()
    ;
}

Microsoft Visual Studio 2008
Version 9.0.21022.8 RTM
Microsoft .NET Framework
Version 3.5

Installed Edition: Enterprise

Microsoft Visual Basic 2008 хххх-ххх-ххххххх-ххххх
Microsoft Visual Basic 2008

Microsoft Visual C# 2008 хххх-ххх-ххххххх-ххххх
Microsoft Visual C# 2008

Microsoft Visual C++ 2008 хххх-ххх-ххххххх-ххххх
Microsoft Visual C++ 2008

Microsoft Visual Studio 2008 Tools for Office хххх-ххх-ххххххх-ххххх
Microsoft Visual Studio 2008 Tools for Office

Microsoft Visual Studio Team System 2008 Architecture Edition хххх-ххх-ххххххх-ххххх
Microsoft Visual Studio Team System 2008 Architecture Edition

Microsoft Visual Studio Team System 2008 Database Edition хххх-ххх-ххххххх-ххххх
Microsoft Visual Studio Team System 2008 Database Edition

Microsoft Visual Studio Team System 2008 Development Edition хххх-ххх-ххххххх-ххххх
Microsoft Visual Studio Team System 2008 Development Edition

Portions of International CorrectSpell™ spelling correction system © 1993 by Lernout & Hauspie Speech Products N.V. All rights reserved.

The American Heritage® Dictionary of the English Language, Third Edition Copyright © 1992 Houghton Mifflin Company. Electronic version licensed from Lernout & Hauspie Speech Products N.V. All rights reserved.


Microsoft Visual Studio Team System 2008 Test Edition хххх-ххх-ххххххх-ххххх
Microsoft Visual Studio Team System 2008 Test Edition

Microsoft Visual Web Developer 2008 хххх-ххх-ххххххх-ххххх
Microsoft Visual Web Developer 2008

Crystal Reports AAJ60-G0MSA4K-68000CF
Crystal Reports Basic for Visual Studio 2008

Differences between LINQ to SQL for SQL Server and SSCE:

Notice the command line tool I referred you to for generating the object-relational mapping. While SQL Server will have a nice designer to do the same thing, atleast till Orcas, SQL Compact will have to do with SqlMetal command line tool. No designer support. (If you prefer command line tools like me, you shall have no problem!)

Note: SQLMetal extracts SQL metadata from your database and generates a source file containing entity class declarations. Alternatively, you can split the process into two steps, first generating an XML file representing the SQL metadata and then later translating that XML file into a source file containing declarations. This split process allows you to retain the metadata as a file so you may edit it.

LINQ queries are eventually mapped to SQL queries. Since SQL supported by SSC is a strict subset of that on SQL Server, LINQ follows suit. (To see the SQL which is generated, set db.Log = Console.Out where db is the DataContext.).

Stored procedures and views are not supported by SSC, and so will not be supported through LINQ to SQL either.

    [Table(Name="dbo.PERSONNELS")]
    public partial class PERSONNEL : INotifyPropertyChanging, INotifyPropertyChanged
    {
        ....
    }

        interface IPersonnel
    {
        int PERSONNEL_ID { get; set; }
    }

    public partial class PERSONNEL : IPersonnel
    {        
    }

ProxyGenerator generator = new ProxyGenerator();
return (T)generator.CreateProxy(typeof(T), new AsyncProxy(), target);

V>            var query =
V>                from b in db.GroupCountTests
V>                group 
V>                   new  {  b.Code, b.Catalog }
V>                by b.Code into g
V>                where g.Distinct().Count() > 1 
V>                select g;

V>SELECT [t1].[Code] AS [Key]
V>FROM (
V>    SELECT [t0].[Code]
V>    FROM [dbo].[GroupCountTest] AS [t0]
V>    GROUP BY [t0].[Code]
V>    ) AS [t1]
V>WHERE ((
V>    SELECT COUNT(*)
V>    FROM (
V>        SELECT DISTINCT [t2].[Code], [t2].[Catalog]
V>        FROM [dbo].[GroupCountTest] AS [t2]
V>        WHERE (([t1].[Code] IS NULL) AND ([t2].[Code] IS NULL)) OR (([t1].[Code] IS NOT NULL) AND ([t2].[Code] IS NOT NULL) AND ([t1].[Code] = [t2].[Code]))
V>        ) AS [t3]

exec sp_executesql N'SELECT [t0].[Code], [t0].[Catalog]
FROM [dbo].[GroupCountTests] AS [t0]
WHERE @x1 = [t0].[Code]',N'@x1 nvarchar(3)',@x1=N'ХХХХ'

V>SELECT SomeDayID, DayValue
V>FROM SomeDays
V>WHERE DayValue in
V>(
V>SELECT DayValue
V>FROM SomeDays
V>GROUP BY DayValue
V>HAVING COUNT(*) > 1
V>)

var q = from b2 in db.GroupCountTests
         join b1 in
             (from b in db.GroupCountTests
              group b by b.Code into g
              where g.Count() > 1
              select g)
            on b2.Code equals b1.Key
         select b2;

SELECT [t0].[Code], [t0].[Catalog]
FROM [dbo].[GroupCountTests] AS [t0]
INNER JOIN (
    SELECT COUNT(*) AS [value], [t1].[Code]
    FROM [dbo].[GroupCountTests] AS [t1]
    GROUP BY [t1].[Code]
    ) AS [t2] ON [t0].[Code] = [t2].[Code]
WHERE [t2].[value] > 1