В мире SharePoint. Автор SharePoint Engineer Belarus SharePoint User Group Lead. - презентация

1 в мире SharePoint

2 Автор SharePoint Engineer Belarus SharePoint User Group Lead.

3 ? архитектура

4 Сдвиг фокуса «Лучше день потерять, а потом за пять минут долететь» © Гриф

5 План Разработка архитектуры Коммуникация Внедрение Контроль Повторное использование

6 Да будет свет! Разработка архитектуры

7 Общие принципы Separation of concerns Single Responsibility principle Principle of Least Knowledge Dont repeat yourself (DRY) Minimize upfront design

8 Разработка архитектуры Положительные особенности SharePoint Authentication Authorization Communication Deployment Performance Data Access API

9 Разработка архитектуры

10 Разделение на слои Минимум 1 слой (SharePoint Layer) Максимум N слоев В среднем – 5

11

12 1 SharePoint Layer Web Parts Features Receivers Timer Jobs Elements Definitions Workflows*

13 1 SharePoint Layer Presentation Layer User Controls Application Pages Альтернатива – самостоятельный слой

14 1 SharePoint Layer Он есть всегда Может состоять из нескольких независимых проектов Создается c помощью VS templates Содержит единицы развертывания WSP

15 2 Domain Logic Layer Бизнес-требования, переведенные в код

16 2 Domain Logic Layer Создается по мере необходимости Обычная.NET сборка Главный субъект модульного тестирования

17 3 Data Access Layer Repository Row Data Gateway Table Data Gateway Active Record Service Locator

18 3 Data Access Layer Создается по мере необходимости Обычная.NET сборка Особенно полезна при работе с разнородными источниками данных Может включать логику List Throttling

19 4 Domain Entities SPMetal как основа Создается сразу Определения и свойства Нет методов Расширена за счет Partial Class

20 4 Domain Entities Вынесена отдельно Автогенерация Нет логики Но Может стать ядром Domain Logic Layer Расширить Partial Class методами

21 5 Common Services Layer 2 типа общих сервисов Хелперы Shared Services Applications

22 5 Common Services Layer 2 типа общих сервисов Хелперы Shared Services Applications (DAL)

23 5 Common Services Layer Constants GUIDs Custom Exceptions Extension Methods

24 Архитектуру – в массы Коммуникация

25 Заказчик (business people) Руководитель проекта (ПМ) Аналитик Команда разработчиков

26 Коммуникация Заказчик (business people) «продажа» архитектурных решений Совместно с Business Analyst Обычно с высоты >10 км над уровнем моря Диаграммы компонентов + слоев достаточно Слайды

27 Коммуникация Аналитик (business analyst) Объяснение узких мест (риски) Четкая постановка альтернатив (или/или) Диаграмма компонентов Диаграмма вариантов использования Диаграмма активностей

28 Коммуникация Команда разработчиков (+ ПМ) Объяснение основных принципов Reference Implementation Architecture Guidance

29 Коммуникация Команда разработчиков (+ ПМ) Убедиться, что идеи поняты правильно Убедиться, что идеи приняты и будут исполняться Учесть обратную связь в Architecture Guidance

30 Коммуникация Команда разработчиков (+ ПМ) Убедиться, что идеи поняты правильно Убедиться, что идеи приняты и будут исполняться Учесть обратную связь в Architecture Guidance

31 Оживление франкенштейна. Внедрение

32 Architecture Guidance Document Допущения Ограничения Особенности платформы Основные паттерны

33 Внедрение Deployment Guidance Document Обычно – глава в Architecture Guidance Развертывание Резервное копирование Восстановление Upgrade

34 Внедрение Общие рекомендации Review + update Reference Implementations +

35 Кто не все – того накажем. Контроль

36 Peer Code Review Architecture Review

37 Контроль Сделать Reviews частью процесса Проводить их XP-style Используйте инструменты (MSVS2010U) Обновляйте проектную документацию Заводите «технические истории» Проводите разбор с командой

38 Берегите природу. Повторное использование

39 Общий код Общий компонент Managed Metadata Service Application Workflow Activities

40 Повторное использование Reference Implementation Guidance Documents Patterns

41 А что у вас есть против оборотней? Заключение

42 Не бывает одинаковых проектов, но бывают очень похожие

43 Заключение Архитектура – это здорово. Но лучше успешный проект с плохой архитектурой, чем проваленный проект с хорошей.

44 blog: web: profile: