День добрый. Понимаю что вопрос - немного баян, но все же...
Уже 2 года EDM и LINQ to SQL являются, так сказать, общедоступными технологиями. Предлагаю подвести некие промежуточные итоги. Жизнеспособны ли эти технологии вообще? Скажу прямо, у меня опыт работы с ними практически нулевой, я до сих пор использую ридеры и собственные модели, иногда использую датасеты. Но это как бы уже не модно что ли, вот я и поднял эту тему, заботясь о собственной шкуре, что бы в будущем не попасть в технологический просак.
С LINQ to SQL я не работал вообще. С EDM пытался поработать, как только она появилась. Первое что от этой технологии отвернуло - некий технологический перегруз, хз как это объяснить... всего много - толку мало, но это бог с ним, может просто задачи не подходящие были. Окончательно я забил на EDM когда "ознакомился" с ее "производительностью"!
Вот сейчас на носу новый проект, то что я не буду использовать EDM это однозначно, но еще тешусь надеждами зацепить LINQ to SQL, благо время на освоение пока есть. Стоит ли она того? Прошу глубоких теоретиков пока покурить в сторонке. Желательны мнения практиков использовавших эти технологии в реальный проектах.

Спасибо за ответы. Покопался еще немного в EF и LINQ to SQL, каждому конечно свое, но я не нашел значимых для меня преимуществ. Собственные наработки работают на порядок быстрее, имеют гораздо большую масштабируемость и расширяемость. Может с EF и получишь выигрыш по времени разработки, но думаю он сведется к нулю или вообще уйдет в минус при последующих доработках, короче, мы пока пойдем своим путем:))

Все конечно относительно. Кроме того можно выделить по крайней мере два основных варианта реализации.

Первый - когда приложение непосредственно обращается к СУБД – здесь уже логику на клиента или в хранимые процедуры, или туда и туда, как на практике чаще всего бывает.

Второй вариант – клиент подключается к сервисам – здесь уже вариантов соответственно больше…

Я вообще сторонник полу объектно-ориентированного, полу реляционного подхода.

Система должна выглядеть как конструктор лего, с минимально - целостными объектами, с минимальными связями и минимальной инкапсуляцией, что бы ее можно было в кратчайшие сроки разобрать по кусочкам и собрать в новой модификации.
Потому что, как показывает практика, абсолютное большинство Заказчиков изначально не знают, чего они хотят. У меня не раз возникала ситуация, когда Заказчик, в стадии 90%-ой готовности системы, выдвигал новые требования, из-за которых херилась месячная работа. И такие потери не соизмеримы с выигрышем по времени разработки с применением готовых ORM’ов...

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