Linq to Sql стандарт структуры

Question

Мне было интересно, что такое «правильный» путь при использовании Linq to Sql-model в Visual Studio. Должен ли я создать новую модель для каждого из моих компонентов, скажем Блог , Пользователи , Новости и т. Д., И все они будут отличаться xxxDataContext В каждом из них добавлено таблиц и SPROC .

Или я должен создать один MyDbDataContext и всегда работать против этого?

Что такое за / против ? Моя интуиция говорит мне разделить ее на более мелкие контексты, но мне также кажется, что это может вызвать проблемы по мере расширения проекта?

В чем дело? Помогите мне Stackoverflow:)

Answer 1

При создании контекста данных всегда будут накладные расходы, поскольку необходимо построить модель. В зависимости от количества таблиц в вашей базе данных это может быть не так уж важно. Если это всего 10 таблиц или около того, накладные расходы не будут намного больше, чем для контекста с таблицей, скажем, 1 (извините, у меня нет фактического стресс-тестирования, чтобы показать накладные расходы, но, эй, может быть, это дает мне кое-что для блог в эти выходные) .. При просмотре больших баз данных может быть достаточно издержек, чтобы рассмотреть возможность использования отдельных контекстов.

Основное преимущество, которое я вижу при использовании единого контекста данных, заключается в том, что вы получаете возможность использовать JOIN в своем запросе LINQ, и это будет транслироваться в T-SQL. Где, как будто вы делаете соединение после того, как массивы объектов извлекаются, производительность может быть немного ниже. Кроме того, отслеживание нескольких контекстов данных может привести к путанице, и потребуются хорошие соглашения об именах. Поэтому создать свою собственную модель данных с бизнес-логикой, которая инкапсулирует контексты, было бы немного сложнее. Я сделал это, и это не весело :) 1003 *

Однако, если вы все еще чувствуете, что хотите пойти по этому пути, я бы порекомендовал поместить аналогичные таблицы (к которым вам может потребоваться присоединиться) в том же контексте. Кроме того, в Интернете есть несколько статей, которые рекомендуют использовать общий ресурс MappingSource при использовании нескольких контекстов, использующих один и тот же источник. Информацию об этом можно найти здесь: http://www.albahari.com/nutshell/speedinguplinqtosql.aspx

Извините, я знаю, что это не совсем черно-белый ответ, но, надеюсь, это поможет:)

Дополнительно:

Просто хотел добавить, что я провел небольшой тест и выполнил 20 000 операторов SELECT для таблицы небольшого размера, используя 2 разных контекста данных: DataClasses1DataContext содержал сопоставления со всеми таблицами в БД (всего 4) DataClasses2DataContext содержит одно сопоставление только для одной таблицы

Результаты

Время выполнения 20000 SELECT с использованием DataClasses1DataContext: 00: 00: 10.4843750

Время выполнения 20000 SELECT с использованием DataClasses2DataContext: 00: 00: 10.4218750

Как видите, разница невелика.