DLR, IronPython, etc

[metaclass]

Наткнувшись в процессе проектирования проги на то, что мне одновременно необходимы фичи обычного C# со статической типизацией и фичи динамических языков, полез смотреть на IronPython/DLR и тому подобное. Ну, с ходу того, что меня интересует (адекватная интеграция с DBMS) я не нашел, GUI сложнее чем MessageBox("Hello, world"); тоже и в связи с этим возник вопрос:
На кого рассчитаны все нововведения в .NET 3.5/4.0?
Всякие там LINQ to SQL/Entity Framework/Expression Trees/DLR и прочее, причем production статус этого всего совершенно непонятен, неизвестно, что отомрет, что будет использоваться, итд. Все примеры для этого, которые я видел, они, мягко выражаясь, на уровне "select * from Customers -> УРА, Я ЗНАЮ SQL".

DLR, Expression Trees - рассчитаны на дизайнеров языков, причем в проекте IronScheme от DLR отказались ("but decided to abandon this idea because the DLR branch the project used became out of sync with the trunk, and also because the DLR, according to the developers, could not support the majority of the Scheme's requirements"). Как будто и так языков мало.

В общем, это все выглядит каким-то откровенным гиковством со стороны Microsoft, похоже там всякие выпускники CS факультетов затрахали в мозг менеджмент до состояния "пусть теребят свои монады как хотят, абы нас не трогали".


Это все при том, что высокоуровневые фичи в .NET как были кривые, так и остались, типа медленной отрисовки DataGridView или over-architected мрака в System.ComponentModel.

Comments

[metaclass.livejournal.com]

Я знаю что такое Expression Trees и как они используются в Linq2Sql. Только это нахрен не неправильно, к сожалению, т.к. нарушает Single Responsibility Principle - вместо структуры базы и запросов к ней мы имеем структуру базы, ее отражение в виде кода сгенеренного sqlmetal, запрос в виде LINQ и его конверсия в SQL провайдером. Не говоря уже о том, что этих провайдеров кроме как для MSSQL незаметно особо.
А уж если речь пойдет о чем-то, кроме простых запросов, так вообще святых выноси, Linq2SQL ничего кроме селектов не умеет, вроде.

Вы эти гриды видели? Там есть все, кроме того, что нужно. Например есть группировка в дерево перетаскиванием колонок, или показ динамической жопы люси лущик в ячейке, но нет ленивой подгрузки датасет, тем более что оный датасет вообще непригоден для ленивой работы.

[norguhtar.livejournal.com]

вместо структуры базы и запросов к ней мы имеем структуру базы, ее отражение в виде кода сгенеренного sqlmetal, запрос в виде LINQ и его конверсия в SQL провайдером.

Вы мне таки объясните зачем такой пиндец если это причем и не ORM в чистом виде? Для тех кто не осилил SQL?

[metaclass.livejournal.com]

Ну строго типизированные запросы, как бы. Толк от этого в отсутствие проверки "не поменялась ли база с последнего запуска sqlmetal" неясен.
Отсутствии внятного общего подмножества SQL для разных серверов, неясный статус этого проекта вообще тоже не добавляет радости.

[metaclass.livejournal.com]

Прога свалится при запуске и можно будет пофиксить. А не через месяц работы, когда бухгалтеру придет в голову открыть какой-нибудь очень редко используемый отчет.
Про TDD знаю - если я писать тесты, я до рабочего кода вообще никогда в жизни не доберусь, т.к. буду только заниматься тем, что подгонять тесты под ежедневно меняющиеся требования.

[w00dy.livejournal.com]

> Прога свалится при запуске и можно будет пофиксить. А не через месяц работы, когда бухгалтеру придет в голову открыть какой-нибудь очень редко используемый отчет.

Тю, заведите себе табличку Version и храните там версию схемы базы. Можно ещё что-то хранить, если нужно. При запуске проверяете. Если умеете делать upgrade на лету - делаете, если нет, либо база новее чем ожидает приложение - ругаетесь благим матом.

[metaclass.livejournal.com]

Ага, теперь у нас вместо одной статической проверки типов два места, где все может навернутся - запись при апдейте в таблицу Version и проверка этой таблицы при старте проги.
Кстати, упомянутая в посту необходимость одновременно статической и динамической типизации - это из той же оперы. Часть программы должна оставаться работоспособной вне зависимости от схемы базы, а другая часть должна валится с записью в лог сразу же, не отходя от Main.

[w00dy.livejournal.com]

Проверка таблицы и версии при старте это необходимое зло. Вместо этого вы сейчас сверяете свои классы со схемой или что-то такое. Апдейт же этой таблицы может быть только в одном случае - когда вы накатываете апдейт на базу целиком, а в этом случае всё просто ибо он атомарен - либо прошёл, либо нет.

> Часть программы должна оставаться работоспособной вне зависимости от схемы базы.

Вот не люблю я такое. Я считаю что программа либо работает, и всё от чего она зависит находится в актуальном состоянии, либо не работает. Если у программы есть возможность привести всё в порядок (например работает с базой монопольно или ещё чего-то), она должна это сделать, если нет - есть технический специалист, номер тех.поддержки, etc.

[w00dy.livejournal.com]

> Кстати, а что даст проверка "не поменялась ли база с последнего запуска sqlmetal"?

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

[metaclass.livejournal.com]

А что, уже где-то есть "база и код вместе" и это не выглядит как порождение бреда обкурившегося выпускника MIT?

[w00dy.livejournal.com]

Нет, я хочу сказать что приоритетным является код по отношению к хранилищу, поэтому схема данных находиться в коде, а уже потом каким-то магическим образом ложиться на хранилище. Мне это кажется более логичным, чем востановление кода на основании схемы базы.

[w00dy.livejournal.com]

> Я знаю что такое Expression Trees и как они используются в Linq2Sql.

У вас однобокий взгляд на ситуацию. Я пользовал ORM DevExpress XPO. Он умеет по созданной структуре классов создать схему базы и обновлять с некоторыми ограничениями. У него есть Linq2Xpo провайдер, который много чего умеет выпихивать на сервер (группировки, join, фильтрацию, сортировки). В данном конкретном случае SRP банально соблюдён. Всеми вопросами хранения данных занимается ORM, а что за ним - не особо должно быть интересно (у лезть sql-ем в базу приходилось только когда делал какие-то масштабные апдейты схемы).

> Вы эти гриды видели?

Я не много их видел, а для win forms ещё меньше, но посмотрите на DevExpress. У них достаточно приличный грид, всё что вы написали вроде как умеет (группировку так точно, а кто такая люся лущик я не в курсе ;)

[asinitsyn.livejournal.com]

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

Увы, ОО модель программы не полностью соответствует даталогической модели. Поэтому для сколько-нибудь серьезного применения подобные ORM курят бамбук. Те, которые позволяют совместить правильную схему даннх с вашей правильной структурой классов - это хорошие, годные ORMы. Я таких не знаю.