Linq to SQL - вопрос дизайна

Question

HI, В настоящее время у меня есть одна большая база данных с 35 таблицами (я перетащил все свои таблицы БД в конструктор). Я должен признать, что это очень удобно, потому что у меня есть ORM для моей полной базы данных, а запрос с помощью linq прост и прост.

Мои вопросы: 1. Считаете ли вы плохим проект иметь один текстовый текст с 35 таблицами или я должен разделить его на логические единицы? 2. Существуют ли какие-либо потери производительности за использование такого большого текста данных?

Спасибо, Пини.

Answer 1

Производительность снижается, так как она перестраивает метамодель для всех отображений каждый раз, когда вы создаете новый контекст, но если вы отслеживаете это, и это не вызывает у вас проблем, я бы не беспокоился об этом.

Я склонен использовать DataContexts только для очень небольших проектов, для которых нужно смоделировать лишь несколько таблиц, что-то большее, и это проще в долгосрочной перспективе, если верить более традиционному и зрелому ORM, например, nHibernate. *

Answer 2

Я могу понять твою боль. Конструктор LINQ to SQL не очень хорош в больших моделях. Однако 35 столов не очень большие.

Когда вы можете разделить таблицы на две или более групп, где каждая группа полностью независима от другой (без отношений), в этом случае разделение оправдано IMO, особенно когда группы являются логически разделенными частями. В этом случае вы можете дать каждому контексту собственное имя.

Однако, когда у вас есть отношения между группами, это часто указывает на то, что они являются частью одного домена. При разделении такого домена это означает, что вам придется дублировать таблицы, что может быть раздражающим и непрактичным, но когда одна модель / контекст читает только эту таблицу, это может быть нормально.

Также помните, что расщепление модели может иметь некоторые раздражающие побочные эффекты в вашей архитектуре. Конечно, это зависит от вашей архитектуры. Приложение, над которым я работал, использовал «служебные команды», которые выполняли бизнес-логику от имени уровня представления. Автоматическая конструкция предоставила командам экземпляр DataContext, а наличие нескольких DataContexts сделало этот дизайн довольно разочаровывающим.

Answer 3

• Разделить на логические единицы
• Реальных штрафов за производительность нет, но обзор будет довольно сложным.