Последние пару лет отошел от Майкрософта..
Сейчас приходится возвращаться.
В связи с этим актуален вопрос, не появился ли какой-нибудь
продвинутый фреймворк, упрощающий процесс разработки Веб и десктоп-приложений
на базе современных технологий Microsoft: XAML, LINQ.
Чтобы позволял костяк бизнес-модели (структуру, ограничения) определять в одном месте более менее компатно
и по нему можно было бы генерировать все что нужно: базу, классы linq, дефолтный xaml.
Что-то типа django ))

Интересует сие все же скорее для десктопных (Не Веб) программ.

Как фронтенд, я бы однозначно рекомендовал Silverlight 3 (www.silverlight.net) и WPF. Тогда можно будет использовать один и тот же код и для клиента, и для веба.

Для баз МС рекомендует Entity Framework, но многие используют и хвалят NHibernate.

Ещё вот буквально сегодня ссылка пробежала:
http://www.nakedobjects.org/home/index.shtml
Это к твоему желанию иметь один декларативный слой, а остальные генерить

Можно всю бизнес-логику вынести в app-сервер а виндовые и HTML-ная морды общаються с ним при помощи вэб-сервисов,
писать типа одной морды на ВПФ — оното может и проще — но не все вэб-юзеры любят мелкософт (поэтому не на всех машинах будет фреймворк) да и не все захотят чето грузить и ставить там, а захотят просто поработать с привычной страничкой. Да и в общем то есть 2больших разницы у обычных приложений и HTML-страниц и при скрещивании их во что-то среднее — получицца Франкенштейн )))

Здравствуйте, Кирилл Осенков, Вы писали:

КО>Для баз МС рекомендует Entity Framework, но многие используют и хвалят NHibernate.

Это все временное явление. IT на финише работы которая добавит поддержку LINQ в BL-Toolkit. После того как он закончит выбор будет очевиден .

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, Кирилл Осенков, Вы писали:

КО>>Для баз МС рекомендует Entity Framework, но многие используют и хвалят NHibernate.

VD>Это все временное явление. IT на финише работы которая добавит поддержку LINQ в BL-Toolkit. После того как он закончит выбор будет очевиден .
Никак не могу найти убедительных доводов спрыгнуть с NHibernate в пользу BL-Toolkit. Я скорее на Entity Framework уйду, как только увижу что оно всеръез задумано майкрософтом.

Здравствуйте, Аноним, Вы писали:

А>Никак не могу найти убедительных доводов спрыгнуть с NHibernate в пользу BL-Toolkit. Я скорее на Entity Framework уйду, как только увижу что оно всеръез задумано майкрософтом.
http://ormbattle.net/
Посмотри кто там в лидерах... И на сколько отстали все остальные.

Здравствуйте, WolfHound, Вы писали:

WH>Здравствуйте, Аноним, Вы писали:

А>>Никак не могу найти убедительных доводов спрыгнуть с NHibernate в пользу BL-Toolkit. Я скорее на Entity Framework уйду, как только увижу что оно всеръез задумано майкрософтом.
WH>http://ormbattle.net/
WH>Посмотри кто там в лидерах... И на сколько отстали все остальные.
Да, это видел. Но есть несколько другие критерии, и один из самых важных (важнее скорости) — это апробация.
Судя по вот этому:
http://rsdn.ru/Forum/Info/FAQ.rfd.rfdprojects.aspx

Автор: IT
Дата: 03.07.05

не густо.
Ставить под угрозу новый проект не особо хочется.

Да и... в НХибернейте для простейшего ДАО нам абсолютно не надо знать SQL. Самый простейший пример с BL-Toolkit — наичнается с селектов. Т.е. я меняю бизнесобъект и сразу же обязан в дао подправить запрос. Если это однозначно так — то мне это не по карману.

Здравствуйте, Аноним, Вы писали:

А>Да и... в НХибернейте для простейшего ДАО нам абсолютно не надо знать SQL. Самый простейший пример с BL-Toolkit — наичнается с селектов. Т.е. я меняю бизнесобъект и сразу же обязан в дао подправить запрос. Если это однозначно так — то мне это не по карману.

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

Здравствуйте, Аноним, Вы писали:

А>Ставить под угрозу новый проект не особо хочется.

Если ты испоьзуешь НГибернэйт, то проект уже под угрозой.
Мне даже страшно представить, что было бы если бы РСДН жил бы на гибернэйте.

Здравствуйте, Аноним, Вы писали:

А>Да и... в НХибернейте для простейшего ДАО нам абсолютно не надо знать SQL. Самый простейший пример с BL-Toolkit — наичнается с селектов. Т.е. я меняю бизнесобъект и сразу же обязан в дао подправить запрос. Если это однозначно так — то мне это не по карману.

Вы что гордитесь, что не знаете и не используете SQL?

Здравствуйте, VladD2, Вы писали:

VD>Если ты испоьзуешь НГибернэйт, то проект уже под угрозой.
VD>Мне даже страшно представить, что было бы если бы РСДН жил бы на гибернэйте.

Хотелось бы более детальной информации об рисках, связанных с использованием NHibernate в таком проекте как rsdn.

Здравствуйте, VladD2, Вы писали:

VD>Есть мнение, что запросы — это высокоуровневый способ обработки информации, а применение ООП для обработки данных — тупиковая идея существующая только в следствии ограниченно кругозора и недостатка образования у народных масс.

Связь отношение-класс для простейших операций CRUD себя вполне оправдывает. Если же говорить о сложных выборках, например, для аналитической отчетности, то здесь использовать ORM даже вредно. Так что все зависит от задачи.

Здравствуйте, oleg.agafonov, Вы писали:

OA>Хотелось бы более детальной информации об рисках, связанных с использованием NHibernate в таком проекте как rsdn.

У нас просто не хватит денег на железо. На РСДН используется только прямая работа с SQL и BL-Toolkit.
NHibernate-у к ним и на пушечный выстрел не подойти.

Здравствуйте, oleg.agafonov, Вы писали:

OA>Связь отношение-класс для простейших операций CRUD себя вполне оправдывает.

Ну, да если ресурсы беспредельны, а операций кот наплакал.

OA>Если же говорить о сложных выборках, например, для аналитической отчетности, то здесь использовать ORM даже вредно. Так что все зависит от задачи.

Ну, и зачем тогда вообще такой ОРМ?

Здравствуйте, VladD2, Вы писали:

VD>Есть мнение, что запросы — это высокоуровневый способ обработки информации, а применение ООП для обработки данных — тупиковая идея существующая только в следствии ограниченно кругозора и недостатка образования у народных масс.
Полностью согласен.
Еще бы вместо убогого SQL'я и его кошмарных расширений сделали бы ленивый функциональный язык (LINQ имеет именно такую семантику) было бы вообще супер.

Здравствуйте, Аноним, Вы писали:

А>Да и... в НХибернейте для простейшего ДАО нам абсолютно не надо знать SQL. Самый простейший пример с BL-Toolkit — наичнается с селектов. Т.е. я меняю бизнесобъект и сразу же обязан в дао подправить запрос. Если это однозначно так — то мне это не по карману.
Смотри сюда:
http://code.google.com/p/ormbattle/source/browse/trunk/Tests/Performance/BLToolkitTest.cs
Там всего 2 SQL запроса. Один очищает таблицу до и после теста.
А второй в тесте по имени NativeQueryTest

Здравствуйте, WolfHound, Вы писали:

WH>Еще бы вместо убогого SQL'я и его кошмарных расширений сделали бы ленивый функциональный язык (LINQ имеет именно такую семантику) было бы вообще супер.
Нет, тут сложнее. SQL — изначально основывался на операциях с множествами, у которых главная фича в том, что они могут быть хорошо оптимизированы. И они по своему дизайну не Turing-complete. О том как бы лучше расширить SQL написан не один десяток диссертаций

Тупые методы "взять и всю базу в память загрузить, а потом map-reduce'у скормить" неинтересны.

Здравствуйте, Cyberax, Вы писали:

C>Нет, тут сложнее. SQL — изначально основывался на операциях с множествами, у которых главная фича в том, что они могут быть хорошо оптимизированы.
И что мешает функциональному языку проводить операции над множествами?

C>И они по своему дизайну не Turing-complete.
А всякие там TSQL очень даже Turing-complete. При этом еще и императивные в доску.

C>О том как бы лучше расширить SQL написан не один десяток диссертаций
На какие только темы диссертации не пишут.

C>Тупые методы "взять и всю базу в память загрузить, а потом map-reduce'у скормить" неинтересны.
А императивненько ползать курсором по таблице значит интересно?
А не иметь нормальных средств декомпозиции запросов тоже интересно?