AVK>http://weblogs.asp.net/scottgu/archive/2008/01/07/dynamic-linq-part-1-using-the-linq-dynamic-query-library.aspx

Не, это все не то.
Скорее, нужен плагин к студии, чтобы, написав запрос с использованием IntelliSense и прочей лабуды, можно было встать на запрос, нажать капу, оно бы спросило значения внешних (по отношению к запросу) параметров, с учетом их типов, а потом бы скомпиляло, и выполнило.
Вот только все равно это полноценно скорее всего не получится.. Потому как и параметры могут быть сложными объектами и вообще..
Да, в этом плане SQL конечно чем-то поудобнее.

С другой стороны, можно написать unit-тест с LINQ-запросом, выполнил, проверил результат, прибил тест. Или даже оставил с каким-то ключевым Assert'ом.

VD>Лично я с ним не возился. Так что пусть АВК и IB ответят, если копили... У них должен быть доступ к альфам и т.п.

Доступ к альфам у всех есть, это выходило как CTP или что-то такое...

VD>Это делает SQLMetal. А Entity Framework должен по уму делать обратный процесс. Предоставлять некий дизайнер оперирующий некими высокоуровневыми сущностями (моделью). А уже по модели должна генерироваться БД и классы для ее отображения. Но это все мое видение, которое может не иметь ничего общего с действительностью.

Да там NHibernate от Microsoft просто С поддержкой LINQ и дизайнером.
Ну или что-то очень-очень похожее на NHibernate.

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

iT>Да там NHibernate от Microsoft просто С поддержкой LINQ и дизайнером.
iT>Ну или что-то очень-очень похожее на NHibernate.
в EntityFramework требуется наследование от базового класса, в NHibernate — нет. А это создаёт неудобства при работе с EF в распределённых системах.

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

AVK>>http://weblogs.asp.net/scottgu/archive/2008/01/07/dynamic-linq-part-1-using-the-linq-dynamic-query-library.aspx

iT>Не, это все не то.

Не то, но удобный инструмент для того чтобы сделать то. Еще в ранних версиях LINQ была в примерах как раз такая утилита.

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

AVK>Здравствуйте, Igor Trofimov, Вы писали:

AVK>>>http://weblogs.asp.net/scottgu/archive/2008/01/07/dynamic-linq-part-1-using-the-linq-dynamic-query-library.aspx

iT>>Не, это все не то.

AVK>Не то, но удобный инструмент для того чтобы сделать то. Еще в ранних версиях LINQ была в примерах как раз такая утилита.

Есть еще такая штука как LinqPad
Интелесенса нету, зато удобно смотреть результаты, получающиеся лямбды и запросы к базе...
И большая куча примеров...

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

AVK>Еще в ранних версиях LINQ была в примерах как раз такая утилита.

Интеллисенса там не было. А он не помешал бы.

Здравствуйте, Аноним, Вы писали:
А>в EntityFramework требуется наследование от базового класса, в NHibernate — нет. А это создаёт неудобства при работе с EF в распределённых системах.

В EntityFramework обещают избавиться от наследования от базового класса, тем не менее хоть в NHibernate, хоть в EDF или любом другом ORM на практике часто приходится этот базовый класс вводить искусственно для реализации биндинга, Undo/Redo, Validation, Security и прочей сопутствующей обвязки. В "голом" виде POCO/POJO практически не используется никогда, разве что только для отображения в readonly (frontend какой нибудь).
Что за неудобства в распределенных системах? Ведь все что касается передачи данных настраивается контрактами или атрибутами сериализации.

Кто-нибудь знает как обстоят дела с проблемой потери состояния в Entity Data FrameWork при передаче объектов сервисам.
Последнее предлагаемое решение проблемы — перемапить объект на объект(новый) в сервисе и сохранить новый:
newObject.Name = transferObject.Name;
newObject.Desc = transferObject.Desc;
...
Но это сами понимаете тупость — избавились от ручного маппинга в одном месте, получили в другом.
Как обстоят дела сейчас?

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

С>Что за неудобства в распределенных системах? Ведь все что касается передачи данных настраивается контрактами или атрибутами сериализации.
неудобства в передаче графа
Danny Simmons в своём блоге (http://blogs.msdn.com/dsimmons/) пишет про то, как пытаются решить проблему (EntityBag)

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

С>Но это сами понимаете тупость — избавились от ручного маппинга в одном месте, получили в другом.
С>Как обстоят дела сейчас?

Что мешает сделать автоматический маппер?

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

С>тем не менее хоть в NHibernate, хоть в EDF или любом другом ORM на практике часто приходится этот базовый класс вводить искусственно для реализации биндинга, Undo/Redo, Validation, Security и прочей сопутствующей обвязки

Ну да, настоящим пацанам никакие архитектурные изыски не помеха.

С>>тем не менее хоть в NHibernate, хоть в EDF или любом другом ORM на практике часто приходится этот базовый класс вводить искусственно для реализации биндинга, Undo/Redo, Validation, Security и прочей сопутствующей обвязки

AVK>Ну да, настоящим пацанам никакие архитектурные изыски не помеха.

Ну а куда ты вынесешь общий функционал DDD объектов и коллекций?

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

TK>Что мешает сделать автоматический маппер?
Не слишком ли много мапперов и слоев в которых этот маппинг происходит для одного фреймворка?

A>Danny Simmons в своём блоге (http://blogs.msdn.com/dsimmons/)
Спасибо, хорошая подборочка.

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

С>Ну а куда ты вынесешь общий функционал DDD объектов и коллекций?
вы бы сначала обрисовали функционал.

биндинг — что требуется в базовом объекте чтобы его предков можно было биндить?

Undo/Redo — тут я вообще в прострации, как Undo/Redo операции могут быть реализованы, какой общий функционал у разных классов.

Validation — максимум что я вижу, это наследование от интерфейса с простейшими проверками

Security — пример реализации Security в базовом классе в студию.

Здравствуйте, Ziaw, Вы писали:
Z>вы бы сначала обрисовали функционал.
Коротко по выше перечисленному — Lhotka C# Bussiness Objects 2005 (CSLA).
...
Валидация должна происходить на всех слоях, а не только в Presentation. Иногда с бизес-объектами и без интерфейса есть необходимость работать.

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

Z>>вы бы сначала обрисовали функционал.
С>Коротко по выше перечисленному — Lhotka C# Bussiness Objects 2005 (CSLA).
С>...
С>Валидация должна происходить на всех слоях, а не только в Presentation. Иногда с бизес-объектами и без интерфейса есть необходимость работать.

Ну и что? Для чего здесь общий предок?

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

С>>Коротко по выше перечисленному — Lhotka C# Bussiness Objects 2005 (CSLA).
С>>...
С>>Валидация должна происходить на всех слоях, а не только в Presentation. Иногда с бизес-объектами и без интерфейса есть необходимость работать.

_FR>Ну и что? Для чего здесь общий предок?

Извените, что встряю в разговор.

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

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

TK>>Что мешает сделать автоматический маппер?
С>Не слишком ли много мапперов и слоев в которых этот маппинг происходит для одного фреймворка?

Если вам кажется, что слоев слишком много — скорее всего, вы просто используете инструмент не по назначению.

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

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

Вредное, безграмотное и частое, замечу, убеждение