Каковы преимущества или недостатки использования dbml для запросов linq2sql?

Question

В настоящее время я читаю Pro Asp.Net MVC, и они вручную создают все свои классы сущностей linq2sql и сопоставляют их с атрибутами сопоставления linq.Однако все остальные, кого я вижу (из поисковых запросов Google), говорящие о linq 2 sql, похоже, используют визуальный конструктор для создания всех своих сущностей.Какой способ создания объектов l2s является предпочтительным и каковы преимущества / недостатки каждого из них?

Единственное отличие, которое я заметил до сих пор, заключается в том, что я, похоже, не могу выполнить сопоставление наследования при использовании визуального конструктора, хотя MSDN говорит, что я должен это сделать, так что, возможно, я просто пропускаю это в интерфейсе VS 2010.Однако я не уверен, что мне все равно следует использовать наследование, поскольку это технически может добавить дополнительные объединения, когда мне не нужны данные вложенной таблицы.

Как PS, l2s не будет вносить никаких изменений в мою схему, я буду генерировать изменения схемы вручную, а затем копировать их в linq2sql.

Спасибо,

Answer 1

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

Также обратите внимание, что дизайнер создает частичные классы, вы можете создать дополнительный файл для частичного класса, который включает дополнительные сведения о реализации.Таким образом, когда таблица получает ссылку в конструкторе, это оставляет вам дополнительный код в покое.Мы делаем это, чтобы добавить множество вспомогательных функций к классам, а также предоставить строго типизированные перечислимые свойства, которые накладываются на примитивные целочисленные FK-поля.

Это правда, что хорошо реализовать наследование было бы очень сложно, но я думаю, что если вам нужен такой уровень данных, L2S может быть не лучшим решением.Я предпочитаю поддерживать свой уровень данных чистым и простым, просто используя L2S для ввода и вывода данных, а затем добавляя более сложную логику на бизнес-уровень.Если бы нам действительно нужно было выполнять такие вещи, как наследование объектов на нашем уровне данных, я бы, вероятно, изучил более продвинутую и сложную технологию, такую как EF

Answer 2

Мы создали всю серверную часть нашей платформы приложений с использованием L2S.Я разработал большую часть этого.Я начал использовать конструктор DBML, но быстро понял, что это настоящая боль.Каждое изменение схемы требовало изменения таблиц в конструкторах.Кроме того, все сущности, созданные дизайнером, помещаются в один файл класса и не обладают всей необходимой мне функциональностью, например поддержкой отношений M2M и т. д.Итак, прошло немного времени, прежде чем я понял, что хочу лучшего пути.

В итоге я написал свой собственный генератор кода, который генерирует объекты L2S так, как я хочу, а также генерирует «облегченный» набор объектов, которые используются на уровне приложения.Здесь нет водопровода L2S.Генератор кода создает все эти объекты и другой код непосредственно из целевой базы данных.Больше никакого DBML!

Это сработало для нас очень хорошо, и наши сущности выглядят именно так, как мы хотим, и генерируются автоматически каждый раз, когда меняется схема нашей базы данных.