Domain-Driven Design и CQRS Ведущий: butaji Наши гости: frozen_space и chaliy
Содержание: Что значат все эти буквы, стоит ли изучать?
Список литературы
ЦитатаApplying Domain-Driven Design and Patterns: With Examples in C# and .NET http://www.amazon.com/Applying-Domain-Driven-Design-Patterns-Examples/dp/0321268202 Yahoo group Domain-Driven Design http://tech.groups.yahoo.com/group/domaindrivendesign/ http://www.infoq.com/minibooks/domain-driven-design-quickly http://www.domaindrivendesign.org/ CQRS à la Greg Young http://blog.fohjin.com/blog/2009/11/12/CQRS_a_la_Greg_Young Насколько DDD реально имеет место в проектах?
Действительно ли DDD помогает управлять сложностью?
Сколько паттернов вы запомнили из книги Ивенса?
CQRS – недостаAтки и преимущества
OpenSource примеры
ЦитатаDDDSample http://dddsample.sourceforge.net/ S#arp Architecture http://code.google.com/p/sharp-architecture/ http://www.codeplex.com/dddpds http://www.habanerolabs.com/
Улучшения в разборе HTML Разбор HTML в Internet Explorer Platform Preview был усовершенствован и теперь лучше отвечает черновику спецификации HTML5. Generic Элементы Раньше Internet Explorer понимал “generic” элементы (неизвестные HTML элементы без атрибута xmlns) не так, как это описано в спецификации HTML5 – браузер их просто игнорировал. Это означало, что разработчики должны были использовать div элементы с некоторыми CSS классами для того, чтобы получить удовлетворительный результат в Internet Explorer. В Internet Explorer Platform Preview это поведение было изменено и теперь он парсит неизвестные элементы. Читать полностью
Многие разработчики так или иначе застревают в определенной “нише” в плане того, с чем они имеют дело. Например, разработчики Asp.Net фокусируются на таких вещах как jQuery и AJAX. Если разработчик долго работает в одной области, то он скорее всего (я по себе говорю) не особо знает, для чего нужны остальные технологии в стеке. А в [...]
MongoDB очень быстрая NoSQL документоориентированная СУБД, есть множество обзоров её производительности, некоторые говорят что она лучше, некоторые говорят что хуже. Я не буду никого убеждать, скажу для меня она лучше (я не знаю как настроить SQL СУБД для того что бы 5 миллионов записей/транзакций со связями между 2-3 таблицами для каждой записи можно было добавить меньше чем за сутки на обычном железе, может Вы знаете, тогда эта статья не для Вас ))) ). Из NoSQL, монго примечательна встроенными средствами для кластеризации, живым сообществом, где всегда можно спросить совета, попросить добавить новую функцию, а иногда и поспорить с разработчиками о спорных архитектурных решениях. Кстати о архитектурных решениях – монго быстрая именно благодаря им, так как не ведёт никаких логов на жёстком диске, и сбрасывает информацию на диск блоками раз в 60 секунд, есть возможность указать СУБД что нужно сбросить данные сейчас. Обратная сторона медали – надёжности от монго работающей на одной машине ждать не стоит. Читать полностью
Продолжим знакомство с нового встроенного сервиса маршрутизации, позволяющего на основе данных, содержащихся в передаваемом сообщении, выполнять переадресацию запроса другому сервису или сервисам. Таблицы и фильтры – позволяют задать правила маршрутизации сообщений, в частности могут применяться следующие фильтры: на основе полного или частичного совпадению URL адреса, на основе содержимого SOAP конверта (header | body) или собственная логика маршрутизации (для этого потребуется разбирать сообщение самостоятельно). Фильтры сопоставляются с конечными точками (endpoint) сервиса (на который должно быть перенаправлено сообщения) на основе специальной таблицы. При этом с одной конечной точкой (endpoint) можно сопоставить несколько фильтров и определить для них различные приоритеты. WCF в соответствие с указанным приоритетом анализирует все фильтры и находит фильтр, правила которого могут быть применены для входящего сообщения . Т.е. приоритеты не определяют пайплайн применения фильтров, а определяют порядок нахождения наиболее подходящего – как только фильтр найден, то сообщение отправляется на WCF сервис, адрес которого соответствует данному фильтру, и дальнейший анализ фильтров прекращается. <client>
<endpoint name="CalculatorService" address="http://…" binding="basicHttpBinding" contract="*" />
</client>
<routing>
<filters>
<filter name="MatchAllFilter" filterType="MatchAll" />
</filters>
<filterTables>
<filterTable name="mainRoutingTable">
<add filterName="MatchAllFilter" endpointName="CalculatorService" />
</filterTable>
</routingTables>
</routing> В примере выше задается фильтр, соответствующий любому сообщение, а в таблице сопоставляется конечная точка (enpoint) с любым фильтром. Резервные endpoint – это конечные точки (endpoint), которые можно указать как резервные для доставки сообщения, т.е. организовать отказоустойчивую маршрутизацию. <routing>
<filterTables>
<filterTable name="filterTable1">
<add filterName="addFilter" endpointName="CalculatorService1"
alternateEndpoints="backupEndpoints"/>
<add filterName="subFilter" endpointName="CalculatorService1"
alternateEndpoints="backupEndpoints"/>
<add filterName="mulFilter" endpointName="CalculatorService1"/>
<add filterName="divFilter" endpointName="CalculatorService1"/>
</filterTable>
</filterTables>
<backupLists>
<backupList name="backupEndpoints">
<add endpointName="CalculatorService2"/>
</backupList>
</backupLists>
</routing>
Широковещательная рассылка (multicast) – перенаправление сообщений на несколько конечных точек (endpoint) или WCF сервисов. При использовании широковещательной рассылки следует учесть следующие ограничения: поддерживаются только one-way и duplex схемы, а схема request-response не поддерживается. <service>
<endpoint address="" binding="wsHttpBinding" name="" contract="System.ServiceModel.Routing.ISimplexDatagramRouter" />
</service>
<routing>
<filters>
<filter name="wildcardFilter" filterType="MatchAll" />
</filters>
<filterTables>
<filterTable name="filterTable1">
<add filterName="wildcardFilter" endpointName="Target1"/>
<add filterName="wildcardFilter" endpointName="Target2"/>
<add filterName="wildcardFilter" endpointName="Target3"/>
</filterTable>
</filterTables>
</routing>
Смена протокола (protocol bridging) – обеспечивает возможность смены привязки(binding)/протокола между начальной точкой (клиент) и конечной точкой (WCF сервис). Например, взаимодействие между WCF клиентом и WCF сервисом маршрутизации происходит по HTTP (wshttpbinding), а далее между WCF сервисом маршрутизации и конечным WCF сервисом по TCP (nettcpbinding). <services>
<service behaviorConfiguration="routingConfiguration"
name="System.ServiceModel.Routing.RoutingService">
<endpoint address="router"
binding="basicHttpBinding"
name="RoutingServiceEndpoint"
contract="System.ServiceModel.Routing.IRequestReplyRouter" />
</service>
</services>
<client>
<endpoint name="realDestination"
address="net.tcp://localhost:8080/servicemodelsamples/service"
binding="netTcpBinding"
contract="*" />
</client> В примере WCF сервис маршрутизации опубликован по протоколу HTTP (basichtppbinding), тогда как конечный WCF сервис, определенный в теге <client>, использует TPC (nettcpbinding). Веб-каст с примерами по обсуждаемым возможностям можно найти на портале TechDays.ru – "WCF 4.0 в примерах. Часть 1.".
Сбор аналитических данных очень важен для веб решений (Если у вас возникает вопрос Почему? Перейдите по ссылке). Проблемы сбора и формирования отчетов также актуальны в Silverlight приложениях. При режиме работы Silverlight приложения в браузере можно интегрироватся с существующими аналитическими сервисами, но для офлайнового или внебраузерного режимов это будет намного сложнее. А если добавить еще и Sketch Flow… Microsoft Silverlight Analytics Framework (MSAF) намного…
Этой заметкой я хочу открыть серию статей о разработке для Windows Phone 7 Series. Мы начнем с того, что рассмотрим философию новой платформы с точки зрения разработчика.Читать дальше
Recent Comments