Здравствуйте, VladD2, Вы писали:
VD>Я в курсе. Но в рельсах для создания новой версии БД нужно писать скрипты. Это очень плохой подход. Скрипты еще приемлемы когда мы выпускаем новую версию продукта которая должна будучи проинсталлированной обновить БД у пользователя. Но для развития проектов нам нужна полная автоматика!
По уровню автоматизации нет разницы написать table Product add Details : string в миграции или "public string Details {get {}; set {}}" в классе Product. Разница в нажатиях настолько невелика, что ей можно пренебречь.
Здравствуйте, Ziaw, Вы писали:
Z>Кстати, роадмапе я его выключил из списка ключевых фич, просто по признаку — его можно прикрутить сбоку. Главное сделать простое, удобное и понятное всем ядро. Кто будет ренедрить view по сути дело десятое, одним нравится спарк другим nhaml. Создатель спарка кстати сейчас переманен в команду asp.net, возможно спарк превратится в расширение asp.net.
Беглый взгляд показывает, что мы подобную фигню относительно не сложно можетм на макросе слабать. Обойдемся без внешних зависимостей и сов всеми вкусностями встроенного ДСЛ-я.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Ziaw, Вы писали:
Z>По уровню автоматизации нет разницы написать table Product add Details : string в миграции или "public string Details {get {}; set {}}" в классе Product. Разница в нажатиях настолько невелика, что ей можно пренебречь.
Дело не в нажатиях. Дел в том, что первое — это имератив (указание действий), а второе — декларация. Декларацию можно анализировать, императив — практически нельзя. Его можно только исполнять.
Так что нужно стремится к тому, чтобы если это возможно, опираться на модель, и уж если модель ничем помочь не может, тогда прибегать к императиву.
Так что нажатия не важны. Но обычно и нажатий на декларативные решения тоже меньше приходится.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Ziaw, Вы писали:
Z>>По уровню автоматизации нет разницы написать table Product add Details : string в миграции или "public string Details {get {}; set {}}" в классе Product. Разница в нажатиях настолько невелика, что ей можно пренебречь.
VD>Дело не в нажатиях. Дел в том, что первое — это имератив (указание действий), а второе — декларация. Декларацию можно анализировать, императив — практически нельзя. Его можно только исполнять.
VD>Так что нужно стремится к тому, чтобы если это возможно, опираться на модель, и уж если модель ничем помочь не может, тогда прибегать к императиву.
VD>Так что нажатия не важны. Но обычно и нажатий на декларативные решения тоже меньше приходится.
Я говорил про уровень автоматизации который ты привел в качестве аргумента. Модель в базе, анализировать можно как ее, так и классы которые по ней получены.
Здравствуйте, VladD2, Вы писали:
VD>Так что нужно стремится к тому, чтобы если это возможно, опираться на модель, и уж если модель ничем помочь не может, тогда прибегать к императиву.
Еще одна проблема в том, схема становтися автоматически генерируемой частью приложения. А вот покрыть DDL всех поддерживамых СУБД дело бесперспективное, т.е. все равно рано или поздно придется как-то менять схему БД вне контекста модели, а это будет уже правки сгенеренного исходника. В миграции же мы можем тупо написать нужный скрипт на чистом SQL (например создание материализованной вьюхи или хранимки).
VD>Не. Это сначала написать кучу скриптов, а потом нажать кнопку. А лучше чтобы сразу кнопку.
Сразу не получится. Надо создать модели. Просто другим способом.
Z>>Я не представляю что должен сделать генератор по модели... Z>>
Z>>...имеющий БД с лишней таблицей.
VD>Это не проблема.
Все таки я хочу увидеть ее решение.
Z>>...имеющий БД с недостающей таблицей в которую превратилось строковое поле в одной из предыдущих Z>>...имеющей колонку с не совпадающим типом Z>>
VD>Для таких вещей конечно будут нужны скрипты или ще что-то. Но как раз такого равития нужно избегать. 99% времени у тебя не будет подобных вывертов. А будет плановая реструктуризация. Изменение типов поле, переименования полей, разбиение или слияние таблиц и т.п. Вот это все надо делать в автомате!
Я так и не понял как делать в автомтате
VD>А Решарперу значит довреяшь? Ну, вот и надо создать тоже интеллектуальный инструмент.
Решарпер спрашивает меня какой я хочу сделать рефакторинг, а не делает его сам по каким-то ему ведомым признакам.
VD>Дык ты никогда не получишь чего-то выдающегося если всегда будешь только проверенные решения использовать.
Влад, это нечестный прием. Практика показывает, что работают как раз простые и понятные всем решения. Гениальный апдейтер будут просто бояться исползовать, т.к. предсказать как он себя поведет можно будет только после набивания шишек.
VD>Я вот не встречал построителей парсеров которые позволяли бы отделять грамматику от ее обработчиков и которые бы статически проверяли код, но это не помешало сделать прототипо такого решения .
Я не против создания подобного прототипа, я против объявления этого механизма основным и блокирующим остальную разработку.
Здравствуйте, Ziaw, Вы писали:
Z>Еще одна проблема в том, схема становтися автоматически генерируемой частью приложения. А вот покрыть DDL всех поддерживамых СУБД дело бесперспективное, т.е. все равно рано или поздно придется как-то менять схему БД вне контекста модели, а это будет уже правки сгенеренного исходника. В миграции же мы можем тупо написать нужный скрипт на чистом SQL (например создание материализованной вьюхи или хранимки).
DDL у большинства серверов очень близкий по возможностям. Он же стандартизирован давно. Вот сехмы действительно разые.
Но это фигня. Данная проблема решается путем введения шаблонов генерирующих SQL. Делаем базовый шаблони и их наследники. В наследниках меняем то, что отличается у конкретных серверов.
Здравствуйте, VladD2, Вы писали:
VD>С него и нужно начинать. Это однозначно будет изюминкой проекта.
Я уже писал, что не хочу, чтобы это стало блокером проекта. Тем более, что для изюминки все равно придется написать почти все что нужно для миграций. А с миграциями можно идти дальше.
Z>>Продумать механизм конфига приложения, как минимум строк подключения.
VD>Это у ИТ в БЛтулките уже вроде как сделано.
Мне не нравится идея всех конфигов в одном, смешивать конфиги htttphandler, и приложения мне не хочется, но для начала она пойдет.
Z>>Продумать правила сопоставления имен классов и имен таблиц для разных субд.
VD>А зачем для разных СУБД использовать разные имена для таблиц?
Чтобы в MSSQL видеть таблицы вида MyProduct, а в оракле и фаерберде вида MY_PRODUCT. Впрочем это тоже не критично, но потом поменять будет сложно, для тех кто начал уже использовать.
VD>Не. Этап считается завершенным если мы смогли по БД сгенерировать модель данных, далее изменили эту модель данных, запустили синхронизатор структуры БД и он автоматом обновил стркутуру БД, и при этом не уничтожил данные в БД.
Вот вот, блокер в самом начале. Это плохой план.
Z>>
Milestone 3. Constants.
Z>>На этом этапе хочется уметь генерировать навигационные механизмы для указания View, Controller, Action, и некоторых стандартных урлов без применения магических строк.
VD>Я не силен в ASP.NET MVC, но если я правильно понял, то тут речь идет о неком форкфлоу. Тут тоже есть над чем подумать. Как правильно заметил hardcase, неплохо было бы иметь реализацию локальных продолжений (континюэшонов) на базе которых форкфлову реализуется очень элегантно. Оно как бы живет своей жизнью. Его можно сериализовать, клонировать и перезапускать хоть тысячу раз.
Не хочется задирать порог вхождения отказываясь от привычного всем workflow.
VD>А какова цель viewmodel?
Передать данные от контроллера во вью, чтобы она их показала.
Здравствуйте, VladD2, Вы писали:
VD>DDL у большинства серверов очень близкий по возможностям. Он же стандартизирован давно. Вот сехмы действительно разые.
VD>Но это фигня. Данная проблема решается путем введения шаблонов генерирующих SQL. Делаем базовый шаблони и их наследники. В наследниках меняем то, что отличается у конкретных серверов.
Далеко не так, и на боевых приложениях всегда хочется использовать нюансы конкретной субд. Если для введения хитрого индекса мне придется вникать и писать макросы, я буду плеваться.
Здравствуйте, AndrewVK, Вы писали: AVK>Класс прикладной модели и ad hoc запрос — разные вещи. В модель добавляют вещи с многократным реюзом, на них не грех и отдельный класс завести хотя бы для явной декларации контрактов. А в случае adhoc запросов тебе нужны данные, а не готовая модель.
Нет. В конечном итоге мне нужна именно готовая модель, как "кирпичик" моего приложения.
И если не задумываться об оптимизации, то я могу получить список моделей одним действием:
1) u_list = User.find(:all)
а потом использовать как будто все под рукой:
u_list.each {|u| puts "#{u.fio}, #{u.account.is_admin}"}
С прикладной точки зрения все будет работать.
Но дальше я хочу пооптимизировать и для начала избавиться от циклических запросов зная, что мне понадобятся account.
Уточняем это для ORM-а:
2) u_list = User.find(:all, :include=>[:account])
А дальше я хочу еще оптимизировать, беря из account только одно поле, которое понадобится:
3) u_list = User.find_by_sql("SELECT users.*, accounts.is_admin FROM...
Понимаешь? Я просто провожу последовательную оптимизацию. Правлю одну строчку.
(В случае 3) мне понадобится исправить еще и использование. Вот так: u_list.each {|u| puts "#{u.fio}, #{u.is_admin}"} )
Но никаких новых классов в системе я не создаю. Никакого "скачка сложности" нет при переходе к ad hoc запросу.
И думаю о двух вещах: об модели предметной области, с которой работает приложение и о структурах данных в базе (если мне этого захочется).
Как конвертировать одно в другое — задача ORM.
То есть мне легко тюнить приложение до нужного уровня оптимальности. Рост сложности при этом плавный и не большой.
И на мой взгляд, это ценное качество ActiveRecord.
Здравствуйте, VladD2, Вы писали: VD>Важно. Линк действительно демонстрирует, что то что ты считаешь проблемой — не проблема.
Влад, я знаю, что линк хороший ORM. (Во всяком случае он мне симпатичнее того же хиберната.)
Но речь-то не об этом. Речь о том, что ребята собираются делать фреймворк.
А фреймворк, это не код, это в первую очередь система идей. Причем именно "система", а не свалка.
По хорошему, первый вопрос к "делателям фреймворков": сформулируйте вашу систему идей полностью (как алгебру: определения, аксиомы, теоремы).
Уже после этого многое можно будет сказать о судьбе проекта. Но чтобы создать такую систему нужен талант.
Можно поступить проще, взять готовую систему и перенести в другую область (например, на другой язык).
Но для этого:
— эту систему нужно полностью понять;
— решить задачу отображения на новый язык всех ее компонентов.
Собственно, это я и проверял... (как выяснилось — проблемы уже на первом шаге).
То есть сам подход "взять от некоторые удачные принципы" — безнадежен. Поскольку, как я уже сказл, система — не свалка.
Метод "здесь читаем, здесь не читаем, а здесь рыбу заворачивали" — не проходит. На это уже наступили ребята из питоновской команды, котореые делали pylons. Получилось вроде бы и похоже, вроде бы и использовать можно, а все равно неудобно. (А ведь на питоне делать аналог рельсов куда проще, чем на nemerle.)
В оправдание ребят можно сказать, что копировать рельсы вообще очень сложно. Из-за того, что та система идей которая описывается в статьях и учебных материалах отличается от того, что есть реально в коде. На мой взгляд — преднамеренно. Это как топографические карты в советское время "с искажениями". Обычные туристы даже и не заметят, а враги — пролетят мимо. Часть принципиальных моментов не упоминается, у остальных переставлена значимость. В результате, большинство последователей дружно топают в болото. А тот, кто может разобраться в реальной системе идей рельсов, не станет ее копировать, поскольку способен создать свою, под свой язык и предметную область.
Здравствуйте, Alex EXO, Вы писали:
AE>В оправдание ребят можно сказать, что копировать рельсы вообще очень сложно. Из-за того, что та система идей которая описывается в статьях и учебных материалах отличается от того, что есть реально в коде. На мой взгляд — преднамеренно. Это как топографические карты в советское время "с искажениями". Обычные туристы даже и не заметят, а враги — пролетят мимо. Часть принципиальных моментов не упоминается, у остальных переставлена значимость. В результате, большинство последователей дружно топают в болото. А тот, кто может разобраться в реальной системе идей рельсов, не станет ее копировать, поскольку способен создать свою, под свой язык и предметную область.
Еще раз подчеркну, нет копирования рельс. Есть устранение некоторых недостатков ASP.NET MVC с помощью макросистемы Nemerle. Удачные принципы при этом в основном берутся из рельс, но лишь как из примера хорошей системы. Никто не собирается копировать роровский ORM просто потому, что есть bltoolkit. Никто не собирается клонировать erb. Нет никакого смысла копировать фреймворки тестирования какими бы суперскими они не были. Просто потому, что это ниша .net и там есть свои механизмы для всего этого. Все что планируется сделать до выхода в свет я расписал по шагам здесь
Здравствуйте, Ziaw, Вы писали: Z>Еще раз подчеркну, нет копирования рельс. Есть устранение некоторых недостатков ASP.NET MVC с помощью макросистемы Nemerle. Удачные принципы при этом в основном берутся из рельс, но лишь как из примера хорошей системы.
Ты все-таки рассматриваешь фреймворк как "набор фич"...
Я не особо знаю ASP.NET (поскольку не пишу под виндус), может быть он и является не более чем набором фич.
Ну тогда да, тогда наверное его можно улучшить "с помощью макросистемы Nemerle".
Тогда мы просто понимаем под "фреймворком" совершенно разные вещи и обсуждение не имеет смысла.
Здравствуйте, Alex EXO, Вы писали:
AE>И если не задумываться об оптимизации, то я могу получить список моделей одним действием: AE>1) u_list = User.find(:all) AE>а потом использовать как будто все под рукой: AE>u_list.each {|u| puts "#{u.fio}, #{u.account.is_admin}"} AE>С прикладной точки зрения все будет работать.
А с линком это будет работать уже с оптимизацией. И из БД будут выбираться только нужные поля.
AE>А дальше я хочу еще оптимизировать, беря из account только одно поле, которое понадобится: AE>3) u_list = User.find_by_sql("SELECT users.*, accounts.is_admin FROM...
AE>Понимаешь? Я просто провожу последовательную оптимизацию. Правлю одну строчку.
И что? С чего ты взял, что в случае с линком это невозможно? Более того, вместо втаптывания текста SQL, ты пишешь запрос на статически типизированном основном языке.
AE>Но никаких новых классов в системе я не создаю. Никакого "скачка сложности" нет при переходе к ad hoc запросу.
И ровно то же самое мы имеем в линке.
AE>Как конвертировать одно в другое — задача ORM.
С реляционными данным я хочу работать на полноценном реляционном языке.
Ты уж определись, то ли ты хочешь работать с реляционными данными, как с реляционными данными, то ли ты пытаешься все конвертировать.
Именно в этом заключается ключевое отличие разных видов ORM. Если в рор ОРМ требует работы с графом объектов, то никто его воспроизводить не собирается.
AE>И на мой взгляд, это ценное качество ActiveRecord.
А на мой взгляд ActiveRecord абсолютно негодная вещь.
... << RSDN@Home 1.2.0 alpha 4 rev. 1469 on Windows 7 6.1.7600.0>>
Здравствуйте, AndrewVK, Вы писали: AVK>А с линком это будет работать уже с оптимизацией. И из БД будут выбираться только нужные поля.
Расскажи, как линк определит, какие поля мне дальше понадобятся?
AVK>Ты уж определись, то ли ты хочешь работать с реляционными данными, как с реляционными данными, то ли ты пытаешься все конвертировать.
Сложные выборки хочу делать на реляционном (простые — пофигу на чем).
А вот бизнес-логику предпочитаю писать над объектами. По моему все просто...
Промежуточный слой кортежей и DataSet-ов... ну, лучше бы, что бы о нем не приходилось задумываться.
Однако я лучше соглашусь на него, чем выражать запросы к базе через объектную модель (именно поэтому я Владу и написал, что при отсутствии других вариантов предпочту линк хибернату). Но с AR все равно получается проще.
Начал работу. Немерл оказался в чем-то проще чем я думал. Но некоторые простые моменты стопорят страшно .
Проект и код можно смотреть на: http://code.google.com/p/nemerleonrails/
Здравствуйте, Alex EXO, Вы писали:
AVK>>А с линком это будет работать уже с оптимизацией. И из БД будут выбираться только нужные поля. AE>Расскажи, как линк определит, какие поля мне дальше понадобятся?
По их использованию в самом запросе. Запросы в линке ленивые, и реально исполняются только когда ты их начинаешь итерировать или сворачиваешь в скаляр.
AE>Сложные выборки хочу делать на реляционном (простые — пофигу на чем).
Ну вот линк и есть такой декларативный способ работы с реляционными и иерархическими данными.
AE>Промежуточный слой кортежей и DataSet-ов... ну, лучше бы, что бы о нем не приходилось задумываться.
А и не надо. Ты опять пытаешься в линке увидеть то, чего в нем нет.
AE>Но с AR все равно получается проще.
Чем проще?
... << RSDN@Home 1.2.0 alpha 4 rev. 1469 on Windows 7 6.1.7600.0>>
Здравствуйте, Alex EXO, Вы писали:
AE>Но речь-то не об этом. Речь о том, что ребята собираются делать фреймворк.
Скорее библиотеку. Фрэймворк это базворд родившийся в следствии того, что во многих языках паттерны программирования нельзя заложить в библиотеку. Отсюда появилась необходимость создавать внешние тулы и другую фигню.
В Немерле же, который выбран в качестве средства реализации есть макры с помощью которых в библиотеку можно будет заложить почти все что нужно.
AE>А фреймворк, это не код, это в первую очередь система идей. Причем именно "система", а не свалка.
Ну, вот это не тот случай. Это будет именно библиотечный код который будет все эти идеи реализовывать на практике.
AE>По хорошему, первый вопрос к "делателям фреймворков": сформулируйте вашу систему идей полностью (как алгебру: определения, аксиомы, теоремы).
Мне кажется идея сформулирована весьма конкретно — создать аналог Руби на Рельсах, но на статически типизированном языке поддерживающем макросы.
Ну, а детали они уже будут прорабатываться по ходу дела.
AE>Уже после этого многое можно будет сказать о судьбе проекта.
О судьбе проекта можно будет сказать только когад его начнут делать и что-то начнет получаться (или он загнется).
AE>Но чтобы создать такую систему нужен талант.
О, да, капитан Очевидность! Чтобы сделать что-то стоящее нужен талант, стремление и время!
AE>Можно поступить проще, взять готовую систему и перенести в другую область (например, на другой язык). AE>Но для этого: AE>- эту систему нужно полностью понять; AE>- решить задачу отображения на новый язык всех ее компонентов.
Глупо — прямолинейно переносить на статически типизированный язык решения из динамически типизированного.
Нужно понимать и использовать особенности технологии на которую переносится решение.
AE>Собственно, это я и проверял... (как выяснилось — проблемы уже на первом шаге).
Ты просто плохо разбираешься в возможностях линка. И вместо того чтобы углубиться в этот вопрос вносишь поспешные суждения.
AE>Метод "здесь читаем, здесь не читаем, а здесь рыбу заворачивали" — не проходит. На это уже наступили ребята из питоновской команды, котореые делали pylons. Получилось вроде бы и похоже, вроде бы и использовать можно, а все равно неудобно. (А ведь на питоне делать аналог рельсов куда проще, чем на nemerle.)
Как я уже сказал делать полный аналог нет смысла. Нужно брать задачи и решать их имеющимися средствами. При этом получать те бенефиты которые можно получить и обходить те проблемы которые можно получить в следствии того, что весь процесс работы библиотеки (фрэймворка по вашему) будет протекать во время компиляции.
AE>В оправдание ребят можно сказать, что копировать рельсы вообще очень сложно. Из-за того, что та система идей которая описывается в статьях и учебных материалах отличается от того, что есть реально в коде. На мой взгляд — преднамеренно. Это как топографические карты в советское время "с искажениями".
Ну, а в статьях по Грувийным Рельсам все соответствует действительности?
AE> Обычные туристы даже и не заметят, а враги — пролетят мимо. Часть принципиальных моментов не упоминается, у остальных переставлена значимость. В результате, большинство последователей дружно топают в болото. А тот, кто может разобраться в реальной системе идей рельсов, не станет ее копировать, поскольку способен создать свою, под свой язык и предметную область.
Как я понял, ты считаешь, что знаешь эти моменты. Ну, так поделись с нами этими моментами.
Я не спец в Вебе. Давным давно много работал с СБУД (был пианером SQL-я в этой стране, можно сказать), но сейчас и с ним почти не работаю. Зато я поднаторел с самом Немреле и его макросах, так что я в этом проекте (если он случитя) буду выполнять роль эксперта по Немреле.
Если ты можешь помочь с идеологии, то вперед! Родина тебе не забудет!
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
.
.
