Linq: присоединяться или не вступать (что является лучшим способом, объединением или отношениями) - PullRequest
Новая
       25

Linq: присоединяться или не вступать (что является лучшим способом, объединением или отношениями)

4 голосов
/ 22 июля 2010

Я написал довольно много кода, который использует отношения таблиц Linq2Sql, предоставленные мне просто при наличии внешних ключей в моей базе данных. Но это оказывается немного трудоемким, чтобы высмеивать данные для моих модульных тестов. Я должен вручную установить любые отношения в моем тестовом жгуте.

Итак, мне интересно, если бы написание Linq-соединений вместо того, чтобы полагаться на отношения, дало бы мне более легко тестируемый и возможно более производительный код. 

        var query =
            from orderItem in data.OrderItems
            select new
            {
                orderItem.Order.Reference,
                orderItem.SKU,
                orderItem.Quantity,
            };

        Console.WriteLine("Relationship Method");
        query.ToList().ForEach(x => Console.WriteLine(string.Format("Reference = {0}, {1} x {2}", x.Reference, x.Quantity, x.SKU)));

        var query2 =
            from orderItem in data.OrderItems
            join order in data.Orders
                on orderItem.OrderID equals order.OrderID
            select new
            {
                order.Reference,
                orderItem.SKU,
                orderItem.Quantity,
            };

        Console.WriteLine();
        Console.WriteLine("Join Method");
        query2.ToList().ForEach(x => Console.WriteLine(string.Format("Reference = {0}, {1} x {2}", x.Reference, x.Quantity, x.SKU)));

Оба приведенных выше запроса дают один и тот же результат, но один лучше другого с точки зрения производительности и тестируемости?

Ответы [ 3 ]

2 голосов
/ 22 июля 2010

Что вы тестируете?Linq to SQL способность читать данные?Обычно предполагается, что linq to sql является тонким слоем над базой данных, что сам код linq to sql считается «нетронутым» и, следовательно, не нуждается в проверке.в пользу усложнения вашего кода таким образом, чтобы вы могли смоделировать linq to sql DBML.Если вы хотите проверить свою бизнес-логику, гораздо лучше просто подключить тестовую базу данных к DBML (существует перегрузка конструктора для текста данных, которая позволяет вам это делать) и использовать транзакции базы данных для проверки взаимодействия данных.Таким образом, вы можете откатить транзакцию назад, чтобы отменить изменения в базе данных, оставив тестовую базу данных в ее первоначальном состоянии.

1 голос
/ 22 июля 2010

Я не думаю, что любой из этих подходов имеет преимущество в тестировании производительности или .Впрочем, первую форму легче читать, и я бы с этим согласился.Хотя это субъективный вопрос.

Мне кажется, что ваша проблема заключается в том, что вы можете легко настроить ваши данные, а значения внешнего ключа и ссылки на сущности остаются согласованными.Я не думаю, что это легко решить.Вы могли бы написать некую структуру, которая создает прокси-объекты объектов и использует метаданные сущностей для перехвата FK и установщиков связанных свойств сущностей для их синхронизации, но прежде чем вы это узнаете, вы внедрили базу данных в памяти!*

1 голос
/ 22 июля 2010

С точки зрения производительности оба запроса будут оцениваться по одному и тому же SQL (Скотт Гатри имеет сообщение в блоге о том, как просмотреть SQL, сгенерированный запросами LINQ).Я не думаю, что один из вариантов по своей природе более «тестируемый», чем другой.Однако я предпочитаю использовать внешние ключи и связи, потому что при использовании SQL Metal вы очень быстро узнаете, что ваша база данных имеет соответствующие ключи.

...