Улучшение MonoRail

Мы знаем, что у вас недостаточно документации, но какие другие части вы хотели бы улучшить?

5 ответов

Проблема с ответом на это: как узнать, не хватает ли монорельса какой-либо функции или если из-за плохой документации я просто не знаю об этом.

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


Может быть, это уже есть, и я просто не заметил, но интерфейс Django очень полезен во время разработки. Было бы неплохо иметь что-то подобное для MonoRail.

Новый стабильный релиз также будет приятным, я постоянно буду вафли взад и вперед по вопросу о том, должен ли я использовать выпуск или багажник.


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

Также неясно о зависимостях для соединительной линии - действительно NHibernate 2.0. И когда этот релиз (или есть).


Позвольте мне начать с того, что мы не используем самую последнюю версию Monorail, поэтому это предложение может быть спорным.

Представьте себе два контроллера: BaseController и DerivedController (который получен из BaseController).

Если оба контроллера имеют для них определенные значения, я бы хотел, чтобы он работал интуитивным способом.

Если BaseController спасет для:

  • AException
  • BException

и DerivedController спасет для:

  • AException
  • CException

то

  • Исключение, исключенное из BaseController, должно использовать спасение для AExceptions в BaseController.
  • Исключение, исключенное из DerivedController, должно использовать спасение определяет AExceptions в DerivedController (потому что DerivedController имеет переопределить спасение BaseController).


Я думаю, что если вы посмотрите на MonoRail по сравнению с ASP.NET MVC, то первое, что вы сказали бы, отсутствует, это хорошая документация, поэтому я думаю, что это нужно подчеркнуть. Однако, поскольку вы говорили конкретно о том, что еще, я бы сказал, что следующая вещь - это инструменты для создания контроллеров со списком действий и т.д., Как это делает Ruby on Rails. Я не знаю, есть ли что-то подобное, но я также предлагаю взглянуть на железнодорожные миграции и посмотреть, есть ли там что-нибудь, что вы хотели бы принять. Для меня, хотя я, вероятно, предпочитаю использовать один согласованный язык, а не несколько доменных языков для определенных частей, например, переход от нескольких старых версий к текущим может быть больно, и я редко работал где-то, что людям удалось адекватно сами сохранять сценарии миграции. В то время как ActiveRecord может самостоятельно настроить схему базы данных, потенциально все еще не хватает одной из миграций, способных выполнять ряд изменений, где переход от неизвестной более старой версии к текущей может не всегда давать тот же результат. Я бы также предположил, что если вы ищете сравнения, возможно, и еще более актуальным является то, что у генераторов. Все это очень хорошо известно, что вы можете создать текстовый файл с расширением .VM и т.д., Но если вы сравните с подобными Ruby on Rails, то генераторы там сделают это намного проще и немного быстрее получить желаемый набор контроллеров и представления настроены. Даже просто пара простых генераторов - например, для создания скелета проекта, а другая для создания контроллера с одним или несколькими действиями, в комплекте с представлениями. Также наличие генератора эшафотов, вероятно, завершит мой "верхний 3".

licensed under cc by-sa 3.0 with attribution.