Здравствуйте, Ночной Смотрящий, Вы писали:

_>> В каждом случае можно подобрать оптимальное.
НС>Какое?

Сформулируй конкретный случай и получишь конкретное оптимальное решение.

_>> Но мне чаще всего попадались случаи, когда удобнее всего забирать пользователя целиком (прямо при проверке id сессии).
НС>Ну вот прям на этом сайте — идем в профиль и видим один набор полей пользователя. Щелкаем по закладкам — получаем другие поля. Смотрим сообщения — там третьи поля. Список сообщений или оценок — там опять отдельный набор.

Ты не путай запрос одного пользователя и запрос некого списка. )

_>>Я думаю вполне понятно, как такой API будет использоваться из прикладного кода.
НС>С Add все понятно. Там и в линке IQueryable скорее всего не будет. Что насчет Select то?

Эээ что? ) Вообще то это я спрашивал тебя как будет выглядеть в прикладном коде решение указанной задачи на linq.

НС>Нет, недостаточно. Потому что на практике прежде всего presentation layer определяет вид запроса, причем на каждой форме/страничке камк правило запросы уникальны. Так что же получается? Выборку практически всех данных делает твой специалист, html рисуют верстальщики, скрипты пишут тоже специальные люди. Так кому твое API тогда предназначено? Ненужной обезъянке, втыкающей в контроллер проброс вызова в твое возжеланное API?

Разработчики интерфейса должны определять не "вид запроса", а набор необходимых им данных. А как они получаются и откуда (может вообще из файлов внутреннего формата) — это дело уже других специалистов.

_>>Ну вот если кто-то говорит, что "поддержка нескольких РСУБД — это редчайшее явление", то это просто автоматический диагноз, что человек вообще не в курсе веб-разработки.
НС>Ну ну. Много дон веб-разработал то? А то чета гложут меня смутные сомнения.

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

Кстати, если вспомнить статистику из таких анализов, то можно сделать очень забавный вывод, в контексте нашей дискуссии. Как я уже сказал, большинство веб-движков умеют работать с несколькими СУБД. Но есть и такие, которые действительно умеют только одну. Только вот самое интересное заключается в том, что это за СУБД такая: практически всегда это та самая mysql! Да, да, та самая, которую в этой темке так ругали. Т.е. если бы это была какая-нибудь Oracle с набором уникальных возможностей, то можно было бы сделать вывод, что переносимость невозможна из-за использования этих возможностей. Но тут у нас mysql... Так что очевидно, что авторы просто не осилили написание слоя абстракции, посчитав что и работы с одной такой БД хватит им для нормальной конкуренции (это они зря...). Но технических проблем (о которых в данной темке заявляли некоторые "специалисты") очевидно нет.