Architecture Lifecycle Management In The Share Point World
Download as PPTX, PDF1 like321 views
Документ посвящен управлению жизненным циклом архитектуры в SharePoint, включая принципы разработки и внедрения. Рассматриваются ключевые аспекты архитектуры, такие как разделение на слои, коммуникация между участниками проекта и контроль качества. Также подчеркивается важность повторного использования компонентов и практического применения архитектурных решений для успешного завершения проектов.
Architecture Lifecycle Management In The Share Point World
- 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 Don’t repeat yourself (DRY) Minimize upfront design
- 8. Разработка архитектуры Положительные особенности SharePoint Authentication Authorization Communication Deployment Performance Data AccessAPI
- 10. Разработка архитектуры Разделение на слои Минимум 1 слой (SharePoint Layer) Максимум N слоев В среднем – 5
- 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 сборка Особенно полезна при работе с разнородными источниками данных Может включать логику ListThrottling
- 19. 4 Domain Entities SPMetal как основа Создается сразу Определения и свойства Нет методов Расширена за счет Partial Class
- 20. 4 Domain Entities Вынесена отдельно Автогенерация Нет логики Но Может стать ядром Domain Logic Layer Расширить Partial Class методами
- 21. 5 Common Services Layer 2 типа общих сервисов Хелперы Shared ServicesApplications
- 22. 5 Common Services Layer 2 типа общих сервисов Хелперы Shared ServicesApplications (DAL)
- 23. 5 Common Services Layer Constants GUIDs Custom Exceptions Extension Methods
- 24. Архитектуру – в массы Коммуникация
- 25. Коммуникация Заказчик (business people) Руководитель проекта (ПМ) Аналитик Команда разработчиков
- 26. Коммуникация Заказчик (business people) «продажа» архитектурных решений Совместно с BusinessAnalyst Обычно с высоты >10 км над уровнем моря Диаграммы компонентов + слоев достаточно Слайды
- 27. Коммуникация Аналитик (business analyst) Объяснение узких мест (риски) Четкая постановка альтернатив (или/или) Диаграмма компонентов Диаграмма вариантов использования Диаграмма активностей
- 28. Коммуникация Команда разработчиков (+ ПМ) Объяснение основных принципов Reference Implementation Architecture Guidance
- 29. Коммуникация Команда разработчиков (+ ПМ) Убедиться, что идеи поняты правильно Убедиться, что идеи приняты и будут исполняться Учесть обратную связь в Architecture Guidance
- 30. Коммуникация Команда разработчиков (+ ПМ) Убедиться, что идеи поняты правильно Убедиться, что идеи приняты и будут исполняться Учесть обратную связь в Architecture Guidance
- 32. Внедрение ArchitectureGuidance 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) Обновляйте проектную документацию Заводите «технические истории» Проводите разбор с командой
- 39. Повторное использование Общий код Общий компонент Managed Metadata Service Application Workflow Activities
- 40. Повторное использование Reference Implementation Guidance Documents Patterns
- 41. А что у вас есть против оборотней? Заключение
- 42. Заключение Не бывает одинаковых проектов, но бывают очень похожие
- 43. Заключение Архитектура – это здорово. Но лучше успешный проект с плохой архитектурой, чем проваленный проект с хорошей.
- 44. СПАСИБО! blog: http://vspug.com/sharepointby twitter: @sharepointby web: http://sharepoint.by profile: http://linkedin.com/in/ivanpadabed