Comments 9
Еще года 2 назад видел это в vs2010 до сих пор интересно, использует ли кто-нибудь это
Идея то отлично, если не считать момент что часто надо писать быстро, а смотреть на диаграмы нет времени
Идея то отлично, если не считать момент что часто надо писать быстро, а смотреть на диаграмы нет времени
Как у других не знаю, но у нас внедрение всех этих архитектурных штучек идет тяжело. Зато когда программист доходит до сложного момента бизнес-логики, он вместо того, чтобы забивать себе светлую голову, открывает Activity Diagram привязанную к PBI и пишет код видя то, как оно должно работать. Так что, потихонечку, с проблеммой поддержки в актуальном состояннии, но внедряем. Тут ведь главное видеть пользу, а когда есть пользя — оно по тихоньку, полегоньку, становится привычным и дальше начинаешь думать: «а как мы раньше без этого то работали?»
Пользуясь случаем, Игорь, вы третью часть про MS Research пишите? А то ждемс? ))
Пользуясь случаем, Игорь, вы третью часть про MS Research пишите? А то ждемс? ))
1 архитектурные штучки стоят дорого на самом деле. Они только в старший редакциях VS типа Ultimate.
На работе ни кто такие деньги выделить просто так не даст…
2 я сам пробовал для себя лично это делать, но если честно одному не написать проект чтобы это понадобилась в серьез и ты в голове не мог прокрутить эти диаграммы.
По поводу статей про msr… я же собираю их из своих заметок, которые пишу девушке. Заметки есть, но очень многие из них не очень технические(рассуждения, наблюдения, бытовые моменты, что-то про других людей, которые могут прочесть тут о себе, а их реакцию я не знаю) и их публиковать на «около техническом» ресурсе наверное не стоит. Те, что технические многие требуют доработки, для которого нужно не свободное время, а дольше побыть в msr.
Так, что тяжело сказать, когда будет следующая часть… я прошлую опубликовал 9 дней назад всего.
Первая была за 2 недели до нее. Статья точно будет, но она будет не раньше чем через неделю.
Ну и плюс, статьи надо вычитывать с точки зрения контента, посыла, оформить в качестве статьи и отдельно с точки зрения грамматики(у меня природная безграмотность+ отсутствие русского языка в ms office на моем компьютере личном, а тем более на рабочем, где даже клавиатуры русской нет...)
На работе ни кто такие деньги выделить просто так не даст…
2 я сам пробовал для себя лично это делать, но если честно одному не написать проект чтобы это понадобилась в серьез и ты в голове не мог прокрутить эти диаграммы.
По поводу статей про msr… я же собираю их из своих заметок, которые пишу девушке. Заметки есть, но очень многие из них не очень технические(рассуждения, наблюдения, бытовые моменты, что-то про других людей, которые могут прочесть тут о себе, а их реакцию я не знаю) и их публиковать на «около техническом» ресурсе наверное не стоит. Те, что технические многие требуют доработки, для которого нужно не свободное время, а дольше побыть в msr.
Так, что тяжело сказать, когда будет следующая часть… я прошлую опубликовал 9 дней назад всего.
Первая была за 2 недели до нее. Статья точно будет, но она будет не раньше чем через неделю.
Ну и плюс, статьи надо вычитывать с точки зрения контента, посыла, оформить в качестве статьи и отдельно с точки зрения грамматики(у меня природная безграмотность+ отсутствие русского языка в ms office на моем компьютере личном, а тем более на рабочем, где даже клавиатуры русской нет...)
Использует. После статьи Дмитрия Андреева мы внедрили такую валидацию у себя в продукте.
Ремейк статьи (из местного блога MS) Как проверить приложение на соответствие архитектуре слоев со скринами от VS2012RC :)
На эту статью есть ссылка в самом начале. Вы видимо не обратили внимание. Да, как я уже сказал в тексте статьи, к написанию этой меня подтолкнула именно она. Я просто показал небольшой пример, как строить диаграмму слоев от решения проекта более низкого уровня чем сборки, плюс, надеюсь освятил вопрос автоматической проверки диаграммы слоев при сборке. Дело в том, что я наткнулся на эту возможность только в книге:
до этого я про такую полезную возможность не знал…
до этого я про такую полезную возможность не знал…
Но в процессе работы, сталкиваясь с ограничениями предъявляемыми архитектурой, мы зачастую думаем: «Вот здесь немножко нарушу, это ведь сэкономит мне час времени разработки. Ну а потом, как будет время, поправлю». Но, почему-то, это время так никогда и не наступает.у меня обычно наоборот — наворочу крутой и «правильной» архитектуры, а потом оказывается, что можно было сделать и проще, не занимаясь оверинжинирингом (не менее правильно, но более приспособлено к реальной жизни).
Поэтому такой вопрос: как эта фича соотносится с рефакторингом? Можно ли, буде возникнет необходимость изменить архитектурц, инфорсить новую её версию только для части кода? И т.д.
Вы можете в единицу времени иметь несколько диаграм слоев, к которым могут быть привязаны разные артефакты вашего решения. Т.е. у вас есть глобальная архитектура, которую вы не меняете, и есть архитектура слоев некоторого модуля. Вы занимаетесь рефакторингом модуля, потом убиваете все в диаграмме слоев этого модуля (или не все, а, например, только связи) и потом востанавливаете архитектуру. Собственно именно этот функционал востановления архитектуры меня и подкупил в Layer Diagram-ах.
Sign up to leave a comment.
Автоматический контроль архитектуры в Visual Studio