Подякувати Студентському архіву довільною сумою
Admin
26.02.2023 12:38
Дякуємо, що користуєтесь нашим архівом!
DevioLab
CRYPTO TRADING AUTOMATION
LIVE
AUTOMATED CRYPTO TRADING • BINANCE
Автоматизуйте свій
криптопортфель
Торгові боти DevioLab аналізують крипторинок,
автоматично відкривають і закривають позиції
та керують вашим портфелем на Binance 24/7.
CRYPTO
80 Bots
BINANCE
Spot Trading
TRADING
24 / 7
deviolab.com
Інформація про навчальний заклад
ВУЗ:
Національний університет Львівська політехніка
Інститут:
Не вказано
Факультет:
Не вказано
Кафедра:
Не вказано
Інформація про роботу
Рік:
2013
Тип роботи:
Звіт
Предмет:
Інші
Частина тексту файла (без зображень, графіків і формул):
Міністерство освіти і науки України
НУ »Львівська політехніка»
Звіт
З дисципліни: Основи командної розробки
Розробив:
Група ПІм-41з
Перевірив:
Климаш Т.С.
м. Хмельницький
2012
Тема: Архітектура проекту у Visual Studio.
Мета: розробити архітектуру проекту у Visual Studio.
Коли проектується архітектура додатка, все красиво, логічно і відповідає кращим світовим практикам. Але в процесі роботи, стикаючись з обмеженнями пропонованими архітектурою, ми часто думаємо: «Ось тут трошки порушу, адже це заощадить мені годину часу розробки. Ну а потім, як буде час, поправлю ». Але, чомусь, цей час так ніколи і не настає. На мій погляд, єдиним способом змусити себе, як програміста, слідувати розробленій архітектурі, це навчити середовище розробки всі відхилення і милиці показувати як помилки компіляції. У цьому випадку, якщо код поганий, він відразу буде виправлений, ну а якщо архітектура застаріла, то буде виправлена вона. Тобто в сховище коду завжди буде код відповідної запланованої архітектурі.
Пара слів, про те, що буде підкатом:
Невелика преамбула.
Відновлення архітектури за наявним проектом.
Налаштування Visual Studio і TFS для автоматичного контролю архітектури.
Підготовка демонстраційного проекту Для демонстрації роботи з Layer Diagram, візьмемо проект, трохи ближчий до реальності. Нехай буде шар доступу до даних (Entity Framework) і, власне, шар клієнтських додатків в якому також буде шарувата структура (MVVM). У клієнтському рівні модель буде братися з першого шару, а от шари View і ViewModel будуть розмазані по декільком зборках. Ось так, ці чотири проекти виглядають після створення:
/
Рис.1
Можна змінити Namespace за замовчуванням для створюваних зборок. У цьому прикладі, для 3-х клієнтських зборок заменяєм Default Namespace:
/
Рис.2
Додаємо в проект DAL базу даних і Entity Model. У клієнтських проектах створюємо папки View і ViewModel. Додаємо в них тестові компоненти й класи:
Рис.3
Додавши посилання між проектами, звернення між створеними компонентами і класами, можна отримати граф залежностей приблизно такого вигляду:
/
Рис.4
Якщо розбиття на шари, йде на рівні зборок, то у зв'язку із забороною на циклічні посилання між збірками (інакше не можна визначити порядок побудови), можлива тільки проблема «звернення через шар». Якщо ж у проекті, як в даному випадку, шари розмазані по декільком зборках, причому в рамках однієї збірки є представники різних верств, перетягування проектів / файлів з Solution Explorer-а в Layer Diagram виявляється не ефективним. І тут на допомогу приходить Architecture Explorer, який викликається з головного меню: Architecture -> Windows -> Architecture Explorer. Відразу після відкриття він матиме вигляд:
/
Рис.5
Відновлення діаграми шарів з артефактів рішення Додаємо в рішення модельний проект, вже в нього додаємо Layer Diagram:
/
Рис.6
Тут ми можемо перетяуть з Toolbox-а шари, намалювати залежності, потім довго і наполегливо в ці шари переносити класи з клієнтських проектів. І все це тільки для того, щоб вже на наступний день, коли розробник додасть новий клас, про який ми не знаємо, і до шарів він не прив'язаний, а отже перевірка перестане працювати. Щоб цього уникнути, нам і придасться Architecture Explorer.
/
Рис.7
Зверніть увагу, що всі класи ViewModel опинилися в одному просторі імен (ну нехай в реальному проекті вони будуть в 3-5), і нам тепер можна в діаграму шарів додавати не класи, а цілком простору імен. Виділяємо їх і, не створюючи ніяких шарів, перетягуємо на нашу Layer Diagram:/
Рис.8
До речі, можемо скористатися і функціоналом перетягування проектів з Solution Explorer-а. З Shift-ом виділяємо в ньому ClientApp1, ClientApp2 і Base.Library, хапаємо лівою кнопкою миші і перетягуємо на вільне місце в Layer Diagram:
/
Рис.9
Перейменовуємо новий шар в Presentation, виділяємо два шари (View і View Model) і перетягуємо їх в шар Presentation:
/
Рис.10
Практично все готово, бракує тільки зв'язків. Для того, щоб їх згенерувати, досить викликати контекстне меню на Layer Diagram-е і вибрати пункт Generate Dependencies:/
Рис.11
Тепер, наша діаграма шарів прийняла закінчений вигляд:
/
Рис.12
Автоматичний контроль архітектури
Ну і останній момент, як змусити діаграму шарів автоматично, при кожному побудові перевіряти, що код відповідає архітектурі? Для демонстрації, я в ClientApp1, в папку View додам компонент, який буде безпосередньо звертатися до шару доступу до даних:
/
Рис.13
Запускаємо побудову і бачимо: Build succeeded. Для того, щоб білди при помилках архітектури падали, необхідно відкрити властивості моделі з Solution Explorer-а (через контестное меню або вибрати і натиснути F4) і включити перевірку архітектури:
Ще раз запускам побудову і бачимо, що у нас з'явилися помилки архітектури:
/
Рис.14
Подвійний клік на помилку, відразу привід до місця, в яке забитий милицю. Звичайно, перевірка залежностей призводить до збільшення часу компіляції, тому можна зібрати два рішення, одне з яких працюють розробники (в нього не включати Modeling Project), а друге, з тим же набором проектів і Modeling Project, для автоматичних побудов в Team Foundation Server. У цьому випадку на робочих місцях побудова йде швидше, а контроль архітектури виконується на сервері, причому по помилках побудови, можуть відразу генеруватися баги. Перед тим, як перейти до висновків, невелика ремарка. Все описане в даній статті працює і в Visual Studio 2010 і в Visual Studio 2012. Єдино, потрібна версія Ultimate або Premium.
Висновки:
1. Layer Diagram це інструментарій, про який треба як мінімум знати, і в нових проектах починати застосовувати
2. Автоматична перевірка архітектури дозволить знизити кількість «милиць» забитих в поспіху або по не знанню
3. Правильне іменування просторів імен та застосування Architecture Explorer-а дозволяє істотно скоротити час на відновлення архітектури
Висновок: на лабораторній роботі розробили архітектуру проекту у Visual Studio.
24.02.2013 22:26
Ділись своїми роботами та отримуй миттєві бонуси!
0%
Оголошення від адміністратора