metaclass: (Default)
[personal profile] 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.

Date: 2010-08-04 11:06 am (UTC)
From: [identity profile] norguhtar.livejournal.com

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

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

Date: 2010-08-04 11:09 am (UTC)
From: [identity profile] metaclass.livejournal.com
Ну строго типизированные запросы, как бы. Толк от этого в отсутствие проверки "не поменялась ли база с последнего запуска sqlmetal" неясен.
Отсутствии внятного общего подмножества SQL для разных серверов, неясный статус этого проекта вообще тоже не добавляет радости.
(deleted comment)

Date: 2010-08-04 11:17 am (UTC)
From: [identity profile] metaclass.livejournal.com
Прога свалится при запуске и можно будет пофиксить. А не через месяц работы, когда бухгалтеру придет в голову открыть какой-нибудь очень редко используемый отчет.
Про TDD знаю - если я писать тесты, я до рабочего кода вообще никогда в жизни не доберусь, т.к. буду только заниматься тем, что подгонять тесты под ежедневно меняющиеся требования.

Date: 2010-08-04 11:19 am (UTC)
From: [identity profile] w00dy.livejournal.com
> Прога свалится при запуске и можно будет пофиксить. А не через месяц работы, когда бухгалтеру придет в голову открыть какой-нибудь очень редко используемый отчет.

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

Date: 2010-08-04 11:22 am (UTC)
From: [identity profile] metaclass.livejournal.com
Ага, теперь у нас вместо одной статической проверки типов два места, где все может навернутся - запись при апдейте в таблицу Version и проверка этой таблицы при старте проги.
Кстати, упомянутая в посту необходимость одновременно статической и динамической типизации - это из той же оперы. Часть программы должна оставаться работоспособной вне зависимости от схемы базы, а другая часть должна валится с записью в лог сразу же, не отходя от Main.

Date: 2010-08-04 11:41 am (UTC)
From: [identity profile] w00dy.livejournal.com
Проверка таблицы и версии при старте это необходимое зло. Вместо этого вы сейчас сверяете свои классы со схемой или что-то такое. Апдейт же этой таблицы может быть только в одном случае - когда вы накатываете апдейт на базу целиком, а в этом случае всё просто ибо он атомарен - либо прошёл, либо нет.

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

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

Date: 2010-08-04 11:18 am (UTC)
From: [identity profile] w00dy.livejournal.com
> Кстати, а что даст проверка "не поменялась ли база с последнего запуска sqlmetal"?

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

Date: 2010-08-04 11:23 am (UTC)
From: [identity profile] metaclass.livejournal.com
А что, уже где-то есть "база и код вместе" и это не выглядит как порождение бреда обкурившегося выпускника MIT?

Date: 2010-08-04 11:45 am (UTC)
From: [identity profile] w00dy.livejournal.com
Нет, я хочу сказать что приоритетным является код по отношению к хранилищу, поэтому схема данных находиться в коде, а уже потом каким-то магическим образом ложиться на хранилище. Мне это кажется более логичным, чем востановление кода на основании схемы базы.

Profile

metaclass: (Default)
metaclass

April 2017

S M T W T F S
      1
2345678
9101112 131415
16171819202122
23242526272829
30      

Most Popular Tags

Style Credit

Expand Cut Tags

No cut tags
Page generated Jun. 8th, 2025 07:13 pm
Powered by Dreamwidth Studios