Здравствуйте, Ziaw, Вы писали: Z>Какая проблема передать в метод обработки документ и фамилию подписавшего разными параметрами, не пытаясь засунуть их в один класс?
Н-да...
1. Кроме "фамилии подписавшего" объект может потребоваться расширить много чем... "фамилией согласовавшего", "номером курьера доставившего пакет"...
2. А кто сказал, что дополнительные поля понадобятся именно в этом методе? Это-то как раз не так — методы базового класса ничего про расширения не знаю, те обычно обрабатываются "внешней" функцией. Речь о другом — единожды прочитанный объект используется многократно. В одних случаях это методы базового класса, а в других — анализ дополнительных атрибутов. И чем больше прикладного функционала может опираться на один запрос к базе, тем меньше нагрузка на базу.
AE>>Да мало ли еще что. Вопрос о "смысле" в нашем разговоре не стоит. Разговор только о "возможности". AE>>А уж для чего эту возможность применить пользователи фреймворка найдут. Z>Какой интересный подход, пихайте все возможности которые придут вам в голову, даже если не видите в них смысла. Z>Пользователи найдут им применение.
Неверно. Не "все возможности которые придут вам в голову", а те, которые реально используются в удачном фреймворке.
Которым пользователи уже нашли применение.
В общем, я не вижу смысла в дальнейшем споре. RoR уже неоднократно пытались воспроизвести на других языках и в результате получались тупиковые, неинтересные проекты. Во многих случаях потому, что их авторы считали те или иные сложно реализуемые на их языках фичи RoR "не нужными".
Ну будет еще один мертвый проект, на сей раз на Немерле... Как говорится — ваше дело.
Просто RoR потому и является талантливо сделанным фреймворком, что в нем мало лишнего и почти все фичи имеют свой смысл.
Здравствуйте, Alex EXO, Вы писали:
AE>1. Кроме "фамилии подписавшего" объект может потребоваться расширить много чем... "фамилией согласовавшего", "номером курьера доставившего пакет"...
Все что требуется для метода обработки он должен запросить явно. Мне не нравится паттерн ActiveRecord, особенно когда он начинает требовать композитных классов.
AE>2. А кто сказал, что дополнительные поля понадобятся именно в этом методе? Это-то как раз не так — методы базового класса ничего про расширения не знаю, те обычно обрабатываются "внешней" функцией. Речь о другом — единожды прочитанный объект используется многократно. В одних случаях это методы базового класса, а в других — анализ дополнительных атрибутов. И чем больше прикладного функционала может опираться на один запрос к базе, тем меньше нагрузка на базу.
Нагрузка будет меньше если выбирать только то, что нужно одним запросом, а не джойнить кучу таблиц со всеми полями каждый раз в надежде, что это все понадобится.
Z>>Какой интересный подход, пихайте все возможности которые придут вам в голову, даже если не видите в них смысла. Z>>Пользователи найдут им применение. AE>Неверно. Не "все возможности которые придут вам в голову", а те, которые реально используются в удачном фреймворке. AE>Которым пользователи уже нашли применение.
Что-то я пока не увидел удачного варианта применения.
AE>В общем, я не вижу смысла в дальнейшем споре. RoR уже неоднократно пытались воспроизвести на других языках и в результате получались тупиковые, неинтересные проекты. Во многих случаях потому, что их авторы считали те или иные сложно реализуемые на их языках фичи RoR "не нужными".
Проект не копирует рельсы. Проект пытается взять от них некоторые удачные принципы.
AE>Ну будет еще один мертвый проект, на сей раз на Немерле... Как говорится — ваше дело. AE>Просто RoR потому и является талантливо сделанным фреймворком, что в нем мало лишнего и почти все фичи имеют свой смысл.
Здравствуйте, Alex EXO, Вы писали:
AE>Нет, я хочу чтобы был создан класс прикладной модели. О чем и речь.
Класс прикладной модели и ad hoc запрос — разные вещи. В модель добавляют вещи с многократным реюзом, на них не грех и отдельный класс завести хотя бы для явной декларации контрактов. А в случае adhoc запросов тебе нужны данные, а не готовая модель.
... << RSDN@Home 1.2.0 alpha 4 rev. 1469 on Windows 7 6.1.7600.0>>
Здравствуйте, Ziaw, Вы писали:
Z> имеет из коробки linq ORM (BlToolkit), view engine (Spark view engine), но имеет "разъемы" для замены их на другие.
Я не знаком с Spark view engine. Можно в двух словах описать, что это такое и что он дает?
Что касается по работе с БД... На мой взгляд самый правильный подход — это житие от модели. То есть на некотором ДСЛ-е описываем БД, а стандартный (но хитрый) компонент по этой модели генерирует или обновляет структуру БД (как на стестовых, так и на реальных данных). Что касается опсений, то я еще года два назад имен вполне осезаемое видение того как это можно сделать.
Теперь о том зачем жить от модели...
Для нормальной быстрой разработки нужно чтобы все данные необходимые для разработки лежало в системе контроля версий (скажем SVN). Разработчик должен поставить средства разработки, выкачать проект, нажать F5 в IDE или запустить батник и получить полностью рабочее окружение. Это не сложно реализуется если все данные удается хранить в файлах и они небольшого размера. Как только появляется БД, это становится проблематичным. Нам нужно чтобы БД испльзуемая для разработки автоматически обновлялась и соотвествовала требованиям которые к ней предъявляет код. Причем это дожно делаться автоматом. Конечно для отладки можно каждый раз генерировать БД с нуля и заполнять ее тестовыми данными, но это приводит к некоторым ограничениям. Например, у программиста может быть отдельные БД для тестирования производительности. Их уже в SVN не положишь.
Далее, разработав программу нам нужен максимально простое развертывание. Если базу придется обновлять вручную или придется для этого писать какие-то скрипты (как в РоР), то это будет совсем не здорово. Намного лучше иметь автоматически работающий компонент который при запуске приложения (или отдельной утилиты) сверял бы структуру БД со структурой модели и если они не совпадают, то обновлял бы структуру БД.
Так вот — это реально, хотя и не очень просто в реализации.
Ну, а генерировать модель по БД, конечно, тоже нужно. Но это к счастью не очень сложно. Нужно будет только разработать набор соглашений и генератор кода (того самого ДСЛ-я модели данных).
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
\AVK>>О чем ты вообще? AE>Да, пожалуй разговор и правда не складывается. На разных языках говорим.
+1
AVK>>Пока что ты питаешь какие то странные иллюзии по поводу linq. AE>А разве я вообще о linq? AE>Я о возможности реализации некоторых удобных фич на статически типизированном языке. AE>В прочем — неважно.
Важно. Линк действительно демонстрирует, что то что ты считаешь проблемой — не проблема.
Так что поверь на слово, или разберись в линке и проверь сам.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Далее, разработав программу нам нужен максимально простое развертывание. Если базу придется обновлять вручную или придется для этого писать какие-то скрипты (как в РоР), то это будет совсем не здорово. Намного лучше иметь автоматически работающий компонент который при запуске приложения (или отдельной утилиты) сверял бы структуру БД со структурой модели и если они не совпадают, то обновлял бы структуру БД.
VD> Так вот — это реально, хотя и не очень просто в реализации.
Со всем согласен, кроме этого пункта.
Автоматическая миграция — это не просто "не очень просто", а иногда и невозможно реализовать без ручного написания скриптов. Простейший пример — переименования поля в entity. Имея на руках только модель, никак нельзя определить, было поле переименовано или одно было удалено и добавлено другое. А если рассмотривать более сложные рефакторинги (вынесение колонки во внешную таблицу), то тут вообще урыться можно.
Здравствуйте, Ziaw, Вы писали:
Z>Требуется написать макросы для генерации свойств и атрибутов bltoolkit'а в пустые классы модели помеченные макросом. Свойства генерируются по схеме одноименной с классом таблицы либо таблицы зданной как параметр макроса.
Как я уже говорил. Лучше идти от обратного. Создать модель данных (нечто-воде ER-модели) в виде некоторого ДСЛ-я или ХМЛ-я и по ней генерировать и обновлять БД. Для этого нужно создать довольно умный компонет.
С него и нужно начинать. Это однозначно будет изюминкой проекта.
Кроме того нужна утилита рверс-инжиниринга — генерирующая модель по БД. Особого ума тут не нужно, так как после генерации модели можно будет вносить изменения в нее, а БД обновлять по ней.
Z>Перед началом работы нужно: Z>Дописать абстракции для работы со схемами СУБД поддерживающимыми тулкитом (это можно оформить как часть тулкита, если IT не будет против).
Да. Нужны универсальные средства добычи метаинформации. В принципе этот код удобнее писать на Немерле, так как там будет не мало условной (основанного на условиях) генерации SQL-я под разные виды СУБД.
Z>Продумать механизм конфига приложения, как минимум строк подключения.
Это у ИТ в БЛтулките уже вроде как сделано.
Z>Продумать правила сопоставления имен классов и имен таблиц для разных субд.
А зачем для разных СУБД использовать разные имена для таблиц?
Z>Этап считается завершенным в случае когда для работы с новой таблицей требуется только создать одноименный класс в проекте. Связи между таблицами считаю необязательными на этом этапе, возможно кто-то добрый доделает их параллельно.
Не. Этап считается завершенным если мы смогли по БД сгенерировать модель данных, далее изменили эту модель данных, запустили синхронизатор структуры БД и он автоматом обновил стркутуру БД, и при этом не уничтожил данные в БД.
Короче, не стоит повторять проверенно не удобные решения и замахиваться на малое. Нужно сразу замахиваться на максимальный уровень.
Z>
Milestone 2. Migrations.
Z>Если кто-то не знает что это — http://flux88.com/blog/net-database-migration-tool-roundup/. Z>На этом этапе требуется продумать и реализовать DSL для выполнения миграций в БД (это тоже можно оформить как часть тулкита, сами механизмы по изменению схемы и возможно поддержки версионности, а не DSL). Очень желательно, чтобы DSL умел автоматически строить undo хотя бы для простых ситуаций.
Вот это точно не над. Это убогая идея. Наш синхронизатор структуры БД должен без каких либо дополнительных описаний (миграционных скриптов) менять структуру уже существующей БД. При этом должно быть совершенно по фигу какой версии эта БД. У нас есть только имеющаяся структура БД и требуемая модель. Все остальное реструктуризатор должен сделать сам. В итоге мы должны получить БД требуемой структуры. И все это одним запуском утилиты или специального метода.
Z>Этап считается завершенным если в шаблоне приложения можно легко создавать и гонять вверх/вниз миграции. Интеграцей в студию всего этого можно потом заниматься паралельно.
Ага. И интеграция никакая не нужна. В общем, привыкаем мыслить масштабнее!
Z>
Milestone 3. Constants.
Z>На этом этапе хочется уметь генерировать навигационные механизмы для указания View, Controller, Action, и некоторых стандартных урлов без применения магических строк.
Я не силен в ASP.NET MVC, но если я правильно понял, то тут речь идет о неком форкфлоу. Тут тоже есть над чем подумать. Как правильно заметил hardcase, неплохо было бы иметь реализацию локальных продолжений (континюэшонов) на базе которых форкфлову реализуется очень элегантно. Оно как бы живет своей жизнью. Его можно сериализовать, клонировать и перезапускать хоть тысячу раз.
Z>
Milestone 5. Немного магии.
Z>Здесь я хочу избавиться от классов viewmodel. Точнее сделать их невидимыми для программиста, их поля будут задаваться прямо в контролле макросами.
А какова цель viewmodel?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Lloyd, Вы писали:
L>Со всем согласен, кроме этого пункта.
L>Автоматическая миграция — это не просто "не очень просто", а иногда и невозможно реализовать без ручного написания скриптов. Простейший пример — переименования поля в entity.
Я же сказал, что продумывал уже это. Для переименования полей достаточно ввести не очень красивые но очень эффективные уникальные идентификаторы (GUID-ы). Любой сущности в модели при создании этой сущности присваивается GUID. Далее в БД создается таблица метаинформации. Так что если мы имеет дело с БД созданной по любой версии модели, то мы сможем автоматически преобразовать ее в другую версию, причем как в более новую, так и в более старую. И все это без промежуточных стадий!
L>Имея на руках только модель, никак нельзя определить, было поле переименовано или одно было удалено и добавлено другое. А если рассмотривать более сложные рефакторинги (вынесение колонки во внешную таблицу), то тут вообще урыться можно.
Ну, как видишь, простейшее решение позволяет это все отследить.
У этого решения конечно есть свои проблемы, но они не так страшны. Скажем возможно повреждение или расинхронизация таблиц хранящих дополнительные метаданные, но это можно проверять и требовать исправления проблемы. Ну, и раз уж мы живем от модели, то не черта лазить в БД напрямую. Меняй модель и получай новую структуру БД.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
L>>Имея на руках только модель, никак нельзя определить, было поле переименовано или одно было удалено и добавлено другое. А если рассмотривать более сложные рефакторинги (вынесение колонки во внешную таблицу), то тут вообще урыться можно.
VD>Ну, как видишь, простейшее решение позволяет это все отследить.
Если честно, то не вижу. Например, то же вынесение колонки может быть произведено как с удалением дубликатов, так и с сохранением оных.
Хотя, если цель — исключительно миграция структуры без сохранения данных, то наверное можно сделать.
VD>У этого решения конечно есть свои проблемы, но они не так страшны. Скажем возможно повреждение или расинхронизация таблиц хранящих дополнительные метаданные, но это можно проверять и требовать исправления проблемы. Ну, и раз уж мы живем от модели, то не черта лазить в БД напрямую. Меняй модель и получай новую структуру БД.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Ziaw, Вы писали:
Z>> имеет из коробки linq ORM (BlToolkit), view engine (Spark view engine), но имеет "разъемы" для замены их на другие.
VD>Я не знаком с Spark view engine. Можно в двух словах описать, что это такое и что он дает?
это язык для генерации html более удобный и интуитивный чем шаблоны асп.нет.
для примера проще показать код, он понятен любому знакомому с html и С#.
<viewdata products="IEnumerable[[Product]]"/>
<ul if="products.Any()">
<li each="var p in products">${p.Name}</li>
</ul>
<else>
<p>No products available</p>
</else>
VD>Что касается по работе с БД... На мой взгляд самый правильный подход — это житие от модели. То есть на некотором ДСЛ-е описываем БД, а стандартный (но хитрый) компонент по этой модели генерирует или обновляет структуру БД (как на стестовых, так и на реальных данных). Что касается опсений, то я еще года два назад имен вполне осезаемое видение того как это можно сделать.
Я не хочу начинать с задачи с непонятными перспективами. Если есть желание, прорабатывай этот момент, генерация модели по бд или наоборот для остальной части не так важно.
VD>Теперь о том зачем жить от модели...
VD>Для нормальной быстрой разработки нужно чтобы все данные необходимые для разработки лежало в системе контроля версий (скажем SVN). Разработчик должен поставить средства разработки, выкачать проект, нажать F5 в IDE или запустить батник и получить полностью рабочее окружение. Это не сложно реализуется если все данные удается хранить в файлах и они небольшого размера. Как только появляется БД, это становится проблематичным. Нам нужно чтобы БД испльзуемая для разработки автоматически обновлялась и соотвествовала требованиям которые к ней предъявляет код. Причем это дожно делаться автоматом. Конечно для отладки можно каждый раз генерировать БД с нуля и заполнять ее тестовыми данными, но это приводит к некоторым ограничениям. Например, у программиста может быть отдельные БД для тестирования производительности. Их уже в SVN не положишь.
Рельсы кладут, там 3 БД по умолчанию на проект. Продакшен, дев и тест. И это именно "запустить батник".
VD>Далее, разработав программу нам нужен максимально простое развертывание. Если базу придется обновлять вручную или придется для этого писать какие-то скрипты (как в РоР), то это будет совсем не здорово. Намного лучше иметь автоматически работающий компонент который при запуске приложения (или отдельной утилиты) сверял бы структуру БД со структурой модели и если они не совпадают, то обновлял бы структуру БД.
Это реально просто, нажать дну кнопку.
VD> Так вот — это реально, хотя и не очень просто в реализации.
Это не просто. На практике обычно идет эволюция БД с требованием поддержки всех имеющихся данных. Этот вопрос решается только скриптами миграции.
Я не представляю что должен сделать генератор по модели...
...имеющий БД с лишней таблицей.
...имеющий БД с недостающей таблицей в которую превратилось строковое поле в одной из предыдущих
...имеющей колонку с не совпадающим типом
Я не доверю слишком умным инструментам (кроме решарпера).
VD>Ну, а генерировать модель по БД, конечно, тоже нужно. Но это к счастью не очень сложно. Нужно будет только разработать набор соглашений и генератор кода (того самого ДСЛ-я модели данных).
юзабельных решений для подобной генерации я не встречал, а вот обратные зарекомендовали себя очень хорошо.
Здравствуйте, Lloyd, Вы писали:
L>Если честно, то не вижу.
Не видишь, так не видишь. Спорить уже нет сил.
L>Например, то же вынесение колонки может быть произведено как с удалением дубликатов, так и с сохранением оных. L>Хотя, если цель — исключительно миграция структуры без сохранения данных, то наверное можно сделать.
Если при преобразовании/копировании данных потребуется удалять данные, то данные можно спасать копируя в отдельные таблицы. Конечно при смене версий в двух направлениях данные не востановятся, но для реального развития БД и спасения данных это не обязательно.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Timur_SPB, Вы писали:
T_S>А в чем суть проекта? T_S>Вопрос конечно наивный и простой, но ответ, понятный широким массам — это необходимое условие для киллерапп.
. Реализовать его у меня не получилось — банально нехватило соображалки.
Если он сможет шарить себя между запросами то почему бы и нет. Но делать его надо параллельно разработке движка, ибо для движка он совершенно некритичная фича.
Z>>Html.ActionLink(product.Name, "Show", new {id = product.Id})
Z>>
Z>>Может превартиться в: Z>>
Z>>Action.Show(product.Id).Link(product.Name)
Z>>
Z>>Наличие этого экшена проверит компилятор. Z>>[/list]
VD>Что делает этот код?
Это код для view, формирует ссылку для вызова экшена Show с параметром id=product.Id и текстом product.Name внутри.
VD>И не лучше ли для него более декларативный ДСЛ-ьчик сделать?
Здравствуйте, Ziaw, Вы писали:
Z>это язык для генерации html более удобный и интуитивный чем шаблоны асп.нет. Z>для примера проще показать код, он понятен любому знакомому с html и С#. Z>
Z><viewdata products="IEnumerable[[Product]]"/>
Z><ul if="products.Any()">
Z> <li each="var p in products">${p.Name}</li>
Z></ul>
Z><else>
Z> <p>No products available</p>
Z></else>
Z>
Мне кажется такую штуку проще и лучше реализовать на макрах, а не использовать внешние генераторы. Тогда у нас будет и интеллисенс и другие пряники.
Z>Я не хочу начинать с задачи с непонятными перспективами.
А что тут непонятного? Ты о чем?
Z>Если есть желание, прорабатывай этот момент, генерация модели по бд или наоборот для остальной части не так важно.
Не важно, конечно. Но без этой части другие начинать бесполезно. Как я уже говорил, нам нужно чтобы проекты собирались из запускались (хотя бы тесты) одним кликом.
Z>Рельсы кладут, там 3 БД по умолчанию на проект. Продакшен, дев и тест. И это именно "запустить батник".
Я в курсе. Но в рельсах для создания новой версии БД нужно писать скрипты. Это очень плохой подход. Скрипты еще приемлемы когда мы выпускаем новую версию продукта которая должна будучи проинсталлированной обновить БД у пользователя. Но для развития проектов нам нужна полная автоматика!
VD>>Далее, разработав программу нам нужен максимально простое развертывание. Если базу придется обновлять вручную или придется для этого писать какие-то скрипты (как в РоР), то это будет совсем не здорово. Намного лучше иметь автоматически работающий компонент который при запуске приложения (или отдельной утилиты) сверял бы структуру БД со структурой модели и если они не совпадают, то обновлял бы структуру БД.
Z>Это реально просто, нажать дну кнопку.
Не. Это сначала написать кучу скриптов, а потом нажать кнопку. А лучше чтобы сразу кнопку.
VD>> Так вот — это реально, хотя и не очень просто в реализации.
Z>Это не просто. На практике обычно идет эволюция БД с требованием поддержки всех имеющихся данных. Этот вопрос решается только скриптами миграции.
Уж для БД разработчиков срипты — это точно огромное зло. Все можно описать декларативно. Считай, что модель — это и есть такой скрипт. Только не императивный, а декларативный. А императивный скрипт нужно уметь вычислить на основании двух моделей.
Z>Я не представляю что должен сделать генератор по модели... Z>
Z>...имеющий БД с лишней таблицей.
Это не проблема.
Z>...имеющий БД с недостающей таблицей в которую превратилось строковое поле в одной из предыдущих Z>...имеющей колонку с не совпадающим типом Z>
Для таких вещей конечно будут нужны скрипты или ще что-то. Но как раз такого равития нужно избегать. 99% времени у тебя не будет подобных вывертов. А будет плановая реструктуризация. Изменение типов поле, переименования полей, разбиение или слияние таблиц и т.п. Вот это все надо делать в автомате!
Ну, а если нужны какие-то вещи которые нельзя описать моделью, то конечно унжны скрипты. Но лично я бы предпочел просто не делать такой алхимии в своем проекте.
Z>Я не доверю слишком умным инструментам (кроме решарпера).
А Решарперу значит довреяшь? Ну, вот и надо создать тоже интеллектуальный инструмент.
Z>юзабельных решений для подобной генерации я не встречал, а вот обратные зарекомендовали себя очень хорошо.
Дык ты никогда не получишь чего-то выдающегося если всегда будешь только проверенные решения использовать.
Я вот не встречал построителей парсеров которые позволяли бы отделять грамматику от ее обработчиков и которые бы статически проверяли код, но это не помешало сделать прототипо такого решения .
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VD>Я не знаком с Spark view engine. Можно в двух словах описать, что это такое и что он дает?
Кстати, роадмапе я его выключил из списка ключевых фич, просто по признаку — его можно прикрутить сбоку. Главное сделать простое, удобное и понятное всем ядро. Кто будет ренедрить view по сути дело десятое, одним нравится спарк другим nhaml. Создатель спарка кстати сейчас переманен в команду asp.net, возможно спарк превратится в расширение asp.net.
.
