На свет он вышел практически сразу после рождения и сайт был другой, и доки небольшие были и примеры. Но вот его широкий «пиар» начался действительно гораздо позже, когда уже он сформировался в текущий вид и успел засветиться в серьезных проектах.
Чуток истории. Если я хорошо помню, то Basis Рома начал делать еще в 2006 году, если не раньше. А вот оформление UI он делал при мне году так в 2008 — и за базу он брал оформление OS Windows Vista. Сидел вырезал бекграунды со скриншотов и т.п. :)
Однако у него на текущий момент есть много других «недостатков», которые приходится решать нестандартными методами.
нельзя делать более сложные Route, чем test/{f}/{fd} — маршрут {tr}-{tr} уже не пройдет (как пример: ru-RU)
В отрыве от всего фреймворка сложно использовать его IoC контейнер — приходится извращаться.
Например, если требуется выделить слой DAL на основе встроенного OrmLite и связать его со слоем бизнес логики (а эти все компоненты в других сборках) — то просто получить доступ к контейнеру IoC не получится, а это значит что большинство функций контейнера не доступно. Например нельзя вызывать нигде TryResolveNamed (даже в классе Service), хотя зарегистрировать можно.
Опять же IoC настолько упрощен, что отсутствуют некоторые весьма востребованные вещи — например управление жизненным циклом объекта.
Вмешаться в процесс сериализации задача не тривиальная — внутренний сериализатор настолько упрощен, что, например, обертку вокруг данных приходится делать для всех классов. Просто так получить json вида response {тут описание объекта} очень непросто. Это можно было бы сделать какой-нить настройкой или атрибутом для класса — однако такая вещь отсутсвует. Т.е. если использовать простые описания классов, то для того что бы получить унифицированный вид ответов от сервисов — надо описывать доп контейнеры.
В системе автодокументации тоже много мелочей, из-за которых сложные оисания сделать не просто. К примеру, если в шаблоне задан путь /v1/entities/{params} то пресловутый свагер, будет считать что наша сущность это не entity, а v1.
перечень не полный, выделил те, с которыми наиболее серьезно столкнулся...
Ну и конечно 4 версия внесла много изменений, из-за которой код, написанный под 3-ю версия пришлось переделывать. Основные изменений коснулось части конфигурирования фреймворка. Не мало параметров либо удалили, либо перенесли на други уровни, либо переделали полностью. Совсем не порадовали ограничения введенные в 4 версии особенно всего 10 запросов. Однако из-за открытости кода — эти вещи можно самому поправить :) Только вот о лицензионной чистоте уже можно будет забыть.
К слову vimeo.com/67092568 посмотрите видео Антона, где он в том числе рассказывать, как они работали и работают над игрой. Может некоторые вопросы ваши будут с ответами.
public class MainViewModel : ViewModel
{
public MainViewModel()
{
// Создание команды - вызов DoSimpleCommand.
SimpleCommand = new Command(DoSimpleCommand);
}
/// <summary>
/// The SimpleCommand function.
/// </summary>
private void DoSimpleCommand()
{
// Добавляем сообщение
Messages.Add("Вызываем 'DoSimpleCommand'.");
}
public ICommand SimpleCommand {get; private set;}
}
Попроще будет
Ну и асинхронные команды сейчас намного проще через async/await делать
Пояснение: усыпение потока нужно для того, чтобы не перегружать бесполезной работой процессор. Так как процессорное время в Azure оплачивается, то это действие будет не лишним.
Да все равно будет, процессорное время все равно будет оплачиваться. Пока служба «арендована» — время считается, вне зависимости делает что-то ваш код или нет.
Свойства лучше делать через DependencyProperty. В вашем случае к placeholder нельзя будет ничего привязать. Что помешает использовать такой компонент, например при локализации.
Однако у него на текущий момент есть много других «недостатков», которые приходится решать нестандартными методами.
Например, если требуется выделить слой DAL на основе встроенного OrmLite и связать его со слоем бизнес логики (а эти все компоненты в других сборках) — то просто получить доступ к контейнеру IoC не получится, а это значит что большинство функций контейнера не доступно. Например нельзя вызывать нигде TryResolveNamed (даже в классе Service), хотя зарегистрировать можно.
Опять же IoC настолько упрощен, что отсутствуют некоторые весьма востребованные вещи — например управление жизненным циклом объекта.
Ну и конечно 4 версия внесла много изменений, из-за которой код, написанный под 3-ю версия пришлось переделывать. Основные изменений коснулось части конфигурирования фреймворка. Не мало параметров либо удалили, либо перенесли на други уровни, либо переделали полностью. Совсем не порадовали ограничения введенные в 4 версии особенно всего 10 запросов. Однако из-за открытости кода — эти вещи можно самому поправить :) Только вот о лицензионной чистоте уже можно будет забыть.
Попроще будет
Ну и асинхронные команды сейчас намного проще через async/await делать
Да все равно будет, процессорное время все равно будет оплачиваться. Пока служба «арендована» — время считается, вне зависимости делает что-то ваш код или нет.