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

AP>О чем я и писал два дня назад, средства декомпозиции не развитые, а довольно скудные.

По сравнению с SQL на три головы выше.

AP> Они приводят к неестественным извращениям над кодом.

Что в приведенном мной коде неестественного?

AP>Поэтому естественным способом декомпозиции является декомпозиция близкая к нарезке фрагментов текста.

Ложное утверждение. Особенно когда куски приходится параметризовать. И в случае таких нарезок твой статический чекер идет лесом, так как запрос собирается динамически.

AP> Фрагмент текста можно окружить условным оператором, выделить в метод и т.д. Это естественная нарезка текста

Текста — может быть. А декомпозированный SQL запрос, на практике, в 99% случаев собирается склеиваиванием датасетов и дописыванием в предикаты по AND. Для всего этого возможностей выражений в C# за глаза.
Ты же пытаешься вытащить какие то экзотические случаи, которые не в кажом проекте вообще бывают, и на основании этого заявить, что это все хуже чем фатальнейший прощелк с девэкспириенсом в твоей библиотечке, вылазящий строго на каждом запросе строго при каждой его модификации.
А обоснование я увидел ровно одно — личне тебе некомфортно не видеть SQL. Браво, чо.

НС>>Эксепшен тоже предполагается в SQL генерить?
AP>Не в том направлении мыслишь



AP>, условия для генерации эксепшена не зависят от серверных данных, поэтому эти условия можно вычислять на клиенте.

А это неважно. Наложение эксепшена на ленивое функциональное выражение — жестяная жесть. Такой код должен приводить только к ошибке при компиляции запроса.

НС>>Зато теряется в нем намного намного больше.
AP>Ты сильно переоценивает реальные потери.

Или ты их недооцениваешь. Хотя фик тебя знает, может у тебя в качестве IDE какой нибудь Far или древняя студия без решарпера. Тогда тебя можно понять.