Каковы преимущества или недостатки использования 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!

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