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

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

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

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

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

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

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

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

Да че Вы к этим хнанимкам прицепились?)) На тысячах предприятий учетки тупо на DBF'ках десятилетиями крутятся без всяких хранимок.
Все хорошо в меру! У меня, например, не хватает знаний T-SQL чтобы всю бизнес-логику на SQL Server перенести, но ни я ни мои клиенты особо от этого не страдаем. В секторе крупного бизнеса возможно да - есть смысл, а в сфере мелкого и среднего бизнеса, где я и работаю, как-то и элементарными триггерами обхожусь.