Такие статьи могут сподвигнуть на «попробовать технологию». Но для совсем-совсем новичков, все статьи такого толка страдают одним общим изъяном: куда всё это записать и как запустить?!. Плюс, в статье как-бы невзначай приплетается серверная сторона проекта, создается впечатление, что она магическим образом получилась.
После чего они, чертыхаясь, забивают на конкретную статью и идут разбираться как вообще организовать проект, указать зависимости, и всё такое прочее.
Это без претензий к переводчику, если что, а вообще к такому виду «туториалов»
Но… открыв оригинал я вижу, что пропущены первые вводные строки текста:
As we already know, AngularJS doesn’t come with an out of the box solution for data modeling. In the most abstract way, AngularJS lets us use JSON data as a model in the controller.
Которые сразу намекают на некоторую степень подготовленности читателя. И сразу претензии к тексту снимаются. В текущем же виде перевод напоминает выдранную главу из большого туториала «от и до», где хотелось бы видеть ссылки на начало процесса
К слову, энтерпрайз решениям важно движение данных и их история, которое лучше всего делается на анемичном домене. DDD Фаулера — для работы с состояниям объектов. Как-то так мне видится это.
На эту тему уже высказывались очень многие известные люди помимо Фаулера и компании. Тут ведь все зависит от того, какая идея лежит за самим приложением, какая архитектура используется. Например, есть такой подход CQRS. Сам по себе он говорит только о разделении команд и запросов. Но на практике такая система начинает часто сопрягаться с EventQueue и MessageBus и так далее. И как раз в такой системе Anemic (больше нравится «бескровный») Domain Model как раз кстати.
CQRS известна давно и это не ноу-хау последней пятилетки. Просто такие системы сложнее проектировать и поддерживать. Но у них есть своя ниша. Большинству же приложений хватит «стандартного» подхода, т.е. того который описывается у Фаулера. И в этом плане статья очень полезная, так как смешение ответственностей в классах огромная проблема. И решается она только опытом, когда уже начинаешь понимать, что оставить в доменном объекте, а что унести в сервис.
Спасибо за статью, весьма интересно!
После прочтения сразу приходит на ум шаблон «Стратегия», и не могли бы вы обозначить нюансы использования описанного шаблона в сравнении со статегией с вашей точки зрения?
Надеюсь, что все «обычные» доклады действительно будут транслироваться и записываться, а не так как это было на прошлом TechEd, когда транслировались только первые 6 треков, а самое интересное, что было дальше не транслировалось никак. Да и то что транслировалось было с большими тех.трудностями. Нормальная трансляция была наверно только из 2-3 комнат.
АОП можно не затрагивать совсем в такой статье, но:
В такой статье надо было еще написать о разных атрибутах для атрибутов, это немаловажный фактор. Еще примеры надо было привести, когда идет множественное применение атрибутов, как они могут наследоваться, как этим управлять. Подводные камни с атрибутами какие могут быть. И так далее по теме. А это даже не статья и не заметка, а писанина на полях тетрадки.
Fail Conf по идее должно быть очень полезным мероприятием, так как «истории успеха уникальны, а вот грабли кажется у всех одинаковые». Жаль, что в Мск такое не организуют.
С R# всегда так смешно получается в большинстве компаний куда приходил: многие используют только Ctrl+N и автодополнение более мощное, чем родное предоставляемое IntelliSense.
Больше спасибо за статью!
Завтра как раз иду в побеседовать в компанию и попробую пройтись по этим вопросам. Напишу потом насколько успешно вышло и подготовились ли они, так как хабр там люди скорее всего читают.
Трофейная интеловская кружка, полученная мной за статьи написанные в корпоративный блог. За пример коллегам, чтобы тоже писали статьи, так как политика партии определяется как «главное люди, а не техника». Этой кружке уже года 4 кажется или около того, надеюсь что прослужит долго-долго, как и клавиатура, которой 9 лет уже (даже разъем на ней DIN-5).
Чтобы продать что-то ненужное, надо сначала купить что-то ненужное (с) Матроскин
У меня две мыши Revolution MX уже лет 5 наверно, и менять я их не собираюсь. Все думал новую купить такую же из запасов, но уже нигде не вижу их. Надо поискать в интернет-магазинах будет. А то уже так привык, так привык — любовь уже давно! ;)
Новая мышь, которая пришла на смену MX Revolution мне, например, не нравится и это меня останавливает от покупки и смены моих старых мышей. А остатки в магазинах продаются по драконовым и совершенно неадекватным ценам.
После чего они, чертыхаясь, забивают на конкретную статью и идут разбираться как вообще организовать проект, указать зависимости, и всё такое прочее.
Это без претензий к переводчику, если что, а вообще к такому виду «туториалов»
Но… открыв оригинал я вижу, что пропущены первые вводные строки текста:
Которые сразу намекают на некоторую степень подготовленности читателя. И сразу претензии к тексту снимаются. В текущем же виде перевод напоминает выдранную главу из большого туториала «от и до», где хотелось бы видеть ссылки на начало процесса , чтобы было видно как приложение растет.
К слову, энтерпрайз решениям важно движение данных и их история, которое лучше всего делается на анемичном домене. DDD Фаулера — для работы с состояниям объектов. Как-то так мне видится это.
CQRS известна давно и это не ноу-хау последней пятилетки. Просто такие системы сложнее проектировать и поддерживать. Но у них есть своя ниша. Большинству же приложений хватит «стандартного» подхода, т.е. того который описывается у Фаулера. И в этом плане статья очень полезная, так как смешение ответственностей в классах огромная проблема. И решается она только опытом, когда уже начинаешь понимать, что оставить в доменном объекте, а что унести в сервис.
После прочтения сразу приходит на ум шаблон «Стратегия», и не могли бы вы обозначить нюансы использования описанного шаблона в сравнении со статегией с вашей точки зрения?
В Comdi (я же правильно помню?) учли ошибки? =)
В такой статье надо было еще написать о разных атрибутах для атрибутов, это немаловажный фактор. Еще примеры надо было привести, когда идет множественное применение атрибутов, как они могут наследоваться, как этим управлять. Подводные камни с атрибутами какие могут быть. И так далее по теме. А это даже не статья и не заметка, а писанина на полях тетрадки.
Завтра как раз иду в побеседовать в компанию и попробую пройтись по этим вопросам. Напишу потом насколько успешно вышло и подготовились ли они, так как хабр там люди скорее всего читают.
Трофейная интеловская кружка, полученная мной за статьи написанные в корпоративный блог. За пример коллегам, чтобы тоже писали статьи, так как политика партии определяется как «главное люди, а не техника». Этой кружке уже года 4 кажется или около того, надеюсь что прослужит долго-долго, как и клавиатура, которой 9 лет уже (даже разъем на ней DIN-5).
У меня две мыши Revolution MX уже лет 5 наверно, и менять я их не собираюсь. Все думал новую купить такую же из запасов, но уже нигде не вижу их. Надо поискать в интернет-магазинах будет. А то уже так привык, так привык — любовь уже давно! ;)