От старого DataLayer к LINQ to SQL / Entity Framework - PullRequest
1 голос
/ 06 октября 2009

В SO и Google есть несколько вопросов, «если бы я выбрал тот или иной», а также множество сравнений LINQ2SQL и LINQ2E. Я видел недостатки, отличия, минусы, плюсы, ограничения и т. Д.

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

Я должен добавить материал в «старое» приложение 2.0, которое недавно было перенесено на 3.5 (оно откомпилировано из коробки, с некоторыми предупреждениями тут и там). Поскольку я должен добавить новые вещи, я хочу начать использовать LINQ (2SQL или Entities).

Я работал с Linq2SQL в прошлом, и мне нравится тот факт, что это быстрое и простое в использовании решение ... , если вы не хотите делать что-то слишком странное . Естественная связь 1..1 между таблицами и тому подобным является удачей, если вы пришли из старых «Наборов записей». Также приятно иметь возможность иметь разные точки данных в зависимости от того, с каким набором таблиц вы хотите работать.

По мере роста количества новых возможностей и возможностей я начал рассматривать возможность попробовать Entity Framework вместо Linq2SQL. Что мне не нравится в последнем, так это неспособность обрабатывать отношения Many2Many без использования hack .

Вот тут и вступает Entity Framework. Но , у вас не может быть нескольких «маленьких моделей», как у вас с Linq2Sql и «datacontexts», если вы не жертвуете некоторыми вещи и некоторые другие вещи.

В настоящее время в базе данных 218 таблиц, и она не сильно увеличивается. Время от времени новый стол, но мы не говорим о 10 столах в день. Я бы сказал, что у нас будет «трудное время», когда мы достигнем 250 таблиц в течение следующего года разработки.

Там есть Многие 2 Многие отношения, некоторые только с PK / PK и некоторые с агрегатами (которые Entity Framework не магически обрабатывает , но он может справиться с ними. Это причина, по которой я не хотел бы начинать с Linq2SQL, если hack не будет в порядке и приемлемым методом.

Что бы вы сделали? Скомпрометировать отношения N..N (зная, что даже при наличии взлома он не будет столь же элегантным и «поддерживаемым», как интегрированное решение) и использовать Linq2SQL и его философию «иметь много маленьких данных, которые вы создаете и уничтожаете» или , с другой стороны, продолжить работу с Entity Framework, иметь гигантскую модель данных со всеми таблицами или связями и начать с этого? Даже при создании нескольких моделей есть недостатки (см. Ссылки там), а наличие одной гигантской модели имеет свои недостатки.

Есть также неофициальные комментарии о том, что Microsoft "отбрасывает" Linq2SQL (я сомневаюсь, но вы никогда не знаете). Наша база данных - MSSQL, и я не думаю, что это скоро изменится.

Любой опыт в этой области будет оценен.

Ответы [ 2 ]

1 голос
/ 06 октября 2009

Я имею дело с отношениями многие ко многим в Linq2SQL.

См. здесь , чтобы узнать метод расширения нейро, чтобы решить вашу боль!

Лично я считаю, что использовать одну монолитную модель проще всего.

0 голосов
/ 06 октября 2009

Что бы я сделал в вашей ситуации? Я бы использовал NHibernate и, вероятно, Castle Active Record.

Почему? Потому что это решение предлагает лучшую поддержку для сценариев «реального мира», особенно тех, о которых вы упомянули. NHibernate масштабируется с вашим проектом и не ограничивает вас. Это в основном бесплатно. NHibernate - очень зрелое, хорошо протестированное решение.

Вы не упоминаете NHibernate как нечто, на что вы обращаете внимание, поэтому я не уверен, что вам не понравится в этом отношении (кажется, что вы прочитали достаточно, чтобы встретить этот вариант) .

LinqToSql / EntityFramework не предлагают всего, чего вы не можете получить с помощью NHibernate.

...