Архитектура и дизайн ПО
Целью данного поста является разделение понятия архитектуры и дизайна ПО. Постоянно возникают непонимания чем же эти два понятия отличаются. Одному зачастую приписываются свойства другого.
Итак.
Архитектура ПО — некоторые рамки в пределах которых будет строиться ПО. Например будет ли приложение веб или декстоп, будет ли оно размещено в "облаке" или нет. Будет ли использовать реляционную СУБД или какую-то другую. С какими другими программами придется взаимодействовать и как это делать. Используемые языки и технологии.
Архитектура мало коррелирует с конкретными задачами.
Архитектура определяет подход к решению некоторого класса задач, и наоборот, некоторый класс задач может быть решен определенными архитектурными приемами.
Дизайн ПО — это конкретный набор компонент и связей между ними для решения определенных задач. Для того чтобы заниматься дизайном надо иметь задачи.
Архитектура определяет дизайн. Используемые языки и технологии сильно влияют на используемые паттерны.
Сам процесс дизайна ПО – итеративен по своей природе. Мы придумываем решения задач, создаем прототип, при проверке прототипа возникают новые задачи или больше узнаем существующих.
Архитектура чаще всего статична. В процессе эволюции декстоп приложение не станет веб-сайтом, язык и платформа вряд ли сменится. Некоторые архитектурные решения могут поменяться, но зачастую это приводит к огромным затратам.
Еще раз вкратце. дизайн решает задачи, архитектура создает “окружение” для решения задач.
DataSheet View и Office 2010 x64
Если кто-либо имел счастье работать с SharePoint c помощью Office 2010 64-битной редакции, то обратил внимание что не работает DataSheet View при просмотре таблиц. Выпадает сообщение об отсутствии ActiveX компонент.
Проблема решаема: http://support.microsoft.com/kb/2266203
Unity 2.0
Давненько я не писал про Unity. За это время успела выйти новая версия этого IoC-контейнера и появилась новая версия Enterprise Library.
Первое заметное изменение в Unity: теперь требуется подключать одну сборку Microsoft.Practices.Unity. Хотя AOP для Unity все еще лежит в отдельной сборке Microsoft.Practices.Unit.Interception.
Интерфейс класса UnityContainer расширился методами IsRegistered и свойством Registrations. Последнее позволяет анализировать что мы уже положили в контейнер.
Три больших изменения в резолвинге.
- Теперь можно резолвить Func<T>, который будет возвращать зарегистрированный в контейнере экземпляр T. Аналогично можно резолвить Func<IEnumerable<T>>, который будет возвращать все зарегистрированные в контейнере именованные зависимости типа T. Это дает возможность переконфигурировать контейнер во время работы программы, так чтобы остальной код об этом не знал.
- При наличии нескольких конструкторов в создаваемом классе по-умолчанию выбирается конструктор с максимальным количеством параметров.
- В метод Resolve теперь можно передавать объекты ResolverOverride, позволяющие переопределять поведение Unity при резолвинге.
Добавились два LifetimeManager. HierarchicalLifetimeManager – чтобы дочерние контейнеры резолвили свои экземпляры, а не брали родительский. Это может пригодиться в вебе при создании дочерних контейнеров на каждый запрос. PerResolveLifetimeManager – позволяет переиспользовать один экземпляр в пределах одного вызова метода Resolve.
Подробнее можно почитать в Change Log.
PS. Также есть версия для Silverlight.
PPS. Качать здесь.
Layered Architecture
Что такое “слоеная” архитектура многие себе представляют. Вкратце – все компоненты разделяем на некоторые логические слои, уменьшая связность между слоями. Но вот мало кто может сказать по какому принципу разделять слои и строить между ними взаимодействие.
У меня давно зрел принцип разделения на слои, который я не мог выразить словами. Прочитав вот этот пост я нашел правильную формулировку:
Никакие правки верхнего слоя никак не могут повлиять на нижний.
То есть если вам понадобилось в UI добавить новую форму или сделать в списке настраиваемую сортировку, то это никак не должно повлиять на слои логики и доступа к данным. ( вопрос в зал: ваши приложения соответствуют этому принципу?)
Группировка элементов в XSLT 1.0
По счастливой случайности я активно занимаюсь разработкой на SharePoint 2010. Для отображения данных в нем использует XSTL 1.0 в котором отсутствует оператор for-each-group. Вот чтобы сделать группировку надо написать такой код:
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:key name="имя-индекса" match="элементы-для-друппировки" use="ключ-для-группировки" />
<xsl:template>
<xsl:for-each
select="элементы-для-друппировки[count(. | key('имя-индекса', ключ-для-группировки)[1]) = 1]">
<!--преобразование для группы-->
<xsl:for-each select="key('имя-индекса', ключ-для-группировки)">
<!--преобразование для элементов группы-->
</xsl:for-each>
<!--преобразование для группы-->
</xsl:for-each>
</xsl:template>
</xsl:stylesheet>
