Архитектура NET приложений

Содержание

Слайд 2

Архитектура Microsoft .NET Framework

Базовая библиотека классов (BCL)

Общеязыковая спецификация (CLS)

Общеязыковая среда выполнения (CLR)

Работа

Архитектура Microsoft .NET Framework Базовая библиотека классов (BCL) Общеязыковая спецификация (CLS) Общеязыковая
с данными (SQL, XML, …)

VB

C++

C#

Visual Studio 2010

ASP.NET

F#


WinForms

WPF


Слайд 3

Общая архитектура .NET-приложений

Современные приложения достигли такого уровня развития, что термин «архитектура» в

Общая архитектура .NET-приложений Современные приложения достигли такого уровня развития, что термин «архитектура»
применении к ним уже давно не удивляет
Считается, что «грамотно построить информационную систему, эффективно и надежно функционирующую не проще, чем сконструировать и возвести современное многофункциональное здание»

Слайд 4

Общая архитектура .NET-приложений

Когда речь заходит о Application Architecture, обычно не возникает недостатка

Общая архитектура .NET-приложений Когда речь заходит о Application Architecture, обычно не возникает
в определениях
Есть даже Web-сайты, которые собирают такие определения, см., например, http://www.sei.cmu.edu/architecture/start/community.cfm
Одно из них (техническое) гласит:
Software architecture is an abstraction, or a high-level view of the system. It focuses on aspects of the system that are most helpful in accomplishing major goals, such as reliability, scalability, and changeability. The architecture explains how you go about accomplishing those goals.

Слайд 5

Общая архитектура .NET-приложений

Мы могли бы привести сотни подобных определений, и они все

Общая архитектура .NET-приложений Мы могли бы привести сотни подобных определений, и они
были бы вполне подходящими
Однако, к примеру, если бы мы проектировали приложение для e-mail рассылки, тогда архитектура должна была нам помочь в том, какой тип приложения нам выбрать:
Windows Service
Web Service
console utility
Пакетный файл, запускаемые по расписанию и т.д.
Но: архитектура не включает такие детали как:
Как обрабатывать исключения?
Как измерять производительность?
Как и куда программа логирует ошибки?
Как создать программу переиспользуемой?

Слайд 6

Общая архитектура .NET-приложений

Со временем некоторые известные и широко используемые архитекторами техники проектирования

Общая архитектура .NET-приложений Со временем некоторые известные и широко используемые архитекторами техники
приложений развились и объединились под так называемыми архитектурными стилями
Архитектурный стиль – это набор принципов, высокоуровневая схема, обеспечивающая абстрактную инфраструктуру для семейства систем
Он улучшает секционирование и способствует повторному использованию дизайна благодаря обеспечению решений часто встречающихся проблем
Архитектурные стили (или шаблоны) можно рассматривать как набор принципов, формирующих приложение

Слайд 7

Общая архитектура .NET-приложений

Наиболее известными архитектурными стилями считаются:
N-tier модель, или многоуровневая архитектура
Многослойная (N-layer)

Общая архитектура .NET-приложений Наиболее известными архитектурными стилями считаются: N-tier модель, или многоуровневая
архитектура
Microsoft DNA
Data-centric
Service Oriented Architecture
Plug-in system
Существуют множество других архитектурных стилей

Слайд 8

Общая архитектура .NET-приложений

Среди начинающих разработчиков иногда имеется путаница между многослойной и многоуровневой

Общая архитектура .NET-приложений Среди начинающих разработчиков иногда имеется путаница между многослойной и
архитектурой
Иначе говоря, чем отличаются друг от друга слои и уровни?
Приложения можно разбивать на части, получая физической и логическое представление
В многоуровневой (N-tier) архитектуре мы делим код на разные сборки или наборы сборок физически
У нас, например, может быть сборка для Web-проекта, в другая – для кода, обрабатывающего бизнес-объекты
Если нам нужно разворачивать наше приложение на нескольких серверах, удаленных географически, то нам нужно использовать N-tier архитектуру

Слайд 9

Общая архитектура .NET-приложений

Разделение на слои означает, что мы логически разделяем код, а

Общая архитектура .NET-приложений Разделение на слои означает, что мы логически разделяем код,
все приложение – это часть одной физической сборки
Мы можем распределить код в разные папки с собственным пространством имен, но у нас не будет отдельной сборки для каждого пространства
В отличие от физического представления мы не сможем распределенно разворачивать каждый слой по отдельности
Иначе говоря, tier – это единица развертывания, а layer – это логическое распределение кода по ответственностям

Слайд 10

Общая архитектура .NET-приложений

Общая архитектура .NET-приложений

Слайд 11

Общая архитектура .NET-приложений

Когда мы говорим про многослойные приложения, у всех перед глазами

Общая архитектура .NET-приложений Когда мы говорим про многослойные приложения, у всех перед
всплывает стандартная схема, где имеются слои представлений, слой бизнес-логики, доступа к данным и собственно хранилище данных
Это многим знакомая схема, но когда мы приступаем непосредственно к разработке и проектированию системы мы должны понимать, что за этими квадратиками скрывается, и как они взаимосвязаны

Слайд 12

Общая архитектура .NET-приложений

Так, уровень представления отвечает за форматирование, за представление данных пользователя

Общая архитектура .NET-приложений Так, уровень представления отвечает за форматирование, за представление данных
на различных типах операционных систем различных типов пользовательских интерфейсов, отображение данных, получение ввода данных от пользователей, первоначальная валидация данных и т.д.
Также к уровня представления можно отнести компоненты процесса пользовательского интерфейса

Слайд 13

Общая архитектура .NET-приложений

Если ввод данных в какой-то операции занимает у пользователя много

Общая архитектура .NET-приложений Если ввод данных в какой-то операции занимает у пользователя
времени, если он связан с логическими переходами между различными формами или страницами интерфейса, если необходимы операции возврата пользователя на предыдущие действия, хранения истории изменения его данных, то здесь необходимо выделять отдельно логику по форматированию и отображению данных от логики непосредственно процесса, связанного с вводом данных

Слайд 14

Общая архитектура .NET-приложений

Когда мы оформляем на веб-сайте заказ на покупку, мы проходим

Общая архитектура .NET-приложений Когда мы оформляем на веб-сайте заказ на покупку, мы
несколько шагов по вводу данных, и эти шаги завершаются еще до того, как начинает работать непосредственно бизнес-логика
Связанное выполнение этих шагов должно лежать на компонентах процесса пользовательского интерфейса
То есть, у нас есть несколько шагов заполнения адресных данных, данных, связанных с платежными реквизитами, данных, связанных с доставкой товара
Эти последовательные шаги должны быть связаны через компоненты процесса пользовательского интерфейса

Слайд 15

Общая архитектура .NET-приложений. Компоненты

Уровень бизнес логики

Уровень представления

Уровень данных

Вызывающие
сервисы

Пользователи и Устройства

Источники данных

Внешние
сервисы

Компоненты

Общая архитектура .NET-приложений. Компоненты Уровень бизнес логики Уровень представления Уровень данных Вызывающие
UI

Компоненты UI Процесса

Интерфейсы сервисов

Бизнес компоненты

Бизнес сущности

Бизнес
сценарии

Агенты сервисов

Компоненты логики доступа

Слайд 16

Общая архитектура .NET-приложений

Компонент пользовательского интерфейса отображает данные и фактически является концевой точкой

Общая архитектура .NET-приложений Компонент пользовательского интерфейса отображает данные и фактически является концевой
связи с данными
Важно при разработки компонент пользовательского интерфейса учитывать, что они никогда не должны участвовать в транзакции и могут быть связаны с компонентами процесса пользовательского интерфейса
Компоненты процесса пользовательского интерфейса фактически осуществляют рендеринг данных для пользователя

Слайд 17

Общая архитектура .NET-приложений

Типичные примеры и технологии, используемые для отображения пользовательских компонент разбиваются

Общая архитектура .NET-приложений Типичные примеры и технологии, используемые для отображения пользовательских компонент
на несколько категорий
Первая категория это пользовательский интерфейс Windows, то есть полноценное доступное приложение, которое пользуется всеми возможностями локальных вычислительных ресурсов для работы с пользователем

Слайд 18

Общая архитектура .NET-приложений

Здесь есть несколько возможностей
Мы строим приложение с Windows Forms, пользуемся

Общая архитектура .NET-приложений Здесь есть несколько возможностей Мы строим приложение с Windows
базовыми классами .Net Framework
Можем использовать в своем приложении внедренный HTML, когда помимо Windows Forms мы позволяем отображать в нашем приложении и HTML страницы, включая и страницы со скриптовыми элементами и можем реализовывать интерфейс в виде дополнительных модулей к другим приложениям

Слайд 19

Общая архитектура .NET-приложений

Есть несколько рекомендаций для разработки компонент ориентированных на создание поиска

Общая архитектура .NET-приложений Есть несколько рекомендаций для разработки компонент ориентированных на создание
интерфейса Windows:
использовать связанные элементы управления данных пользователя (это позволяет легко синхронизировать данные между различными панелями отображения)
использовать один источник данных, связанный с различными контроллерами (это позволяет разработчику абстрагироваться от проблем синхронизации введенных пользователем данных с объектом, хранящим эти данные)

Слайд 20

Общая архитектура .NET-приложений

Другая категория пользовательского интерфейса – Web-Interface
Здесь мы пользуемся технологией ASP

Общая архитектура .NET-приложений Другая категория пользовательского интерфейса – Web-Interface Здесь мы пользуемся
.Net
В сам ASP.Net входит набор элементов управления, который позволяет строить Web-Interface, но с другой стороны, позволяет пользоваться нам событийной парадигмой программирования

Слайд 21

Общая архитектура .NET-приложений

Предположим, нам предстоит разработать простую гостевую книгу для нашего сайта
Один

Общая архитектура .NET-приложений Предположим, нам предстоит разработать простую гостевую книгу для нашего
из сценариев так же достаточно прост: пользователь заходит на страничку, нажимает на кнопку с надписью «Показать все записи», а система запрашивает у СУБД и отображает все записи из книги
При разработке системы мы должны создать Web-форму с кнопкой и кодом для получения всех записей из БД
Код размещается внутри ASPX-формы
Затем решение может быть откомпилировано в dll-сборку

Слайд 22

Общая архитектура .NET-приложений

Альтернатива – отделить код (например,C#) от разметки
Далее можно отделить

Общая архитектура .NET-приложений Альтернатива – отделить код (например,C#) от разметки Далее можно
бизнес-логику от пользовательского интерфейса, например, в виде двух разных библиотек классов
Это мы продемонстрируем в дальнейшем

Слайд 23

Общая архитектура .NET-приложений

В WinBased-проекте, который также известен как толстый клиент, многоуровневая архитектура

Общая архитектура .NET-приложений В WinBased-проекте, который также известен как толстый клиент, многоуровневая
может иметь вид:
WindowsForms или WPF – слой презентации (UI или Presentation layer)
C#-код для управления бизнес-логикой (BLL)
Код доступа к данным (возможно, на C#) - DAL
Реальная СУБД – хранилище данных – DataLayer

Слайд 24

Общая архитектура .NET-приложений

DAL – слой доступа к данным – набор классов, инкапсулирующих

Общая архитектура .NET-приложений DAL – слой доступа к данным – набор классов,
методы доступа к данным, типа создания, чтения, изменения удаления (CRUD), и другие операции над данными, находящимися в хранилище данных (data store, data layer)
Иначе, главная задача DAL – это связь с хранилищем (DL)
В качестве DL мы можем использовать СУБД, один или несколько XML- или текстовых файлов и т.д.

Слайд 25

Общая архитектура .NET-приложений

DAL должен действовать как «немой слой» для уровня BLL или

Общая архитектура .NET-приложений DAL должен действовать как «немой слой» для уровня BLL
других сервисов/служб
DAL не должен содержать специфичную логику в своих классах
Он должен использоваться как утилита или помощник (helper class) для загрузки и сохранения данных из/в хранилище данных

Слайд 26

Общая архитектура .NET-приложений

Слой бизнес-логики (или BLL) содержит бизнес-логику и набор правил, специфичных

Общая архитектура .NET-приложений Слой бизнес-логики (или BLL) содержит бизнес-логику и набор правил,
для приложения, и «говорит» слою DAL:
Загрузить данные, к которым он применит правила;
Сохранить данные после того, как к ним были применены правила
Выполнить операции и проверить данные
Слой BLL обычно предоставляет данные вышележащим уровням (например, слой GUI) после применения к ним бизнес-правил
Помимо этого, BLL может содержать обработку ошибок, логирование, стратегии обработки исключительных ситуаций

Слайд 27

Общая архитектура .NET-приложений

Слой UI содержит графические компоненты и файлы типа ASPX, ASCX,

Общая архитектура .NET-приложений Слой UI содержит графические компоненты и файлы типа ASPX,
MasterPages, таблицы стилей и т.д.
Как правило, тип проекта – Website или Web Project в решении Visual Studio solution для технологии ASP.NET
Иногда путают слои DataLayer и DAL
Это не одно и то же, т.к. DAL – код для доступа к данным, а DataLayer – это сама база данных

Слайд 28

Общая архитектура .NET-приложений

На рисунке показано, как слои взаимодействуют друг с другом

Общая архитектура .NET-приложений На рисунке показано, как слои взаимодействуют друг с другом

Слайд 29

Общая архитектура .NET-приложений

Если мы отделим код каждого слоя и разместим каждый из

Общая архитектура .NET-приложений Если мы отделим код каждого слоя и разместим каждый
них в собственном проекте и библиотеке классов, то мы получим 4-уровневый проект: Presentation tier, BL tier, DAL tier и DL tier (физическая БД)
Однако, для web-based приложений мы имеем 3-уровневую архитектуру по умолчанию
Presentation tier – браузер клиента вместо Windows forms)
код web forms, BL и DAL в одной сборке – это Application tier
физическая БД как Data tier
Это архитектура с «тонким клиентом»

Слайд 30

Общая архитектура .NET-приложений

Слой бизнес-логики (BLL) обычно включает следующие компоненты:
Фасад приложения -

Общая архитектура .NET-приложений Слой бизнес-логики (BLL) обычно включает следующие компоненты: Фасад приложения
необязательный компонент , который обеспечивает упрощенный интерфейс для компонентов бизнес-логики, часто объединяя множество бизнес-операций, что упрощает использование бизнес-логики. Это сокращает количество зависимостей, потому что вызывающим сторонам извне нет необходимости знать детали компонентов бизнес-слоя и отношения между ними

Слайд 31

Общая архитектура .NET-приложений

Слой бизнес-логики (BLL) обычно включает следующие компоненты:
Компоненты бизнес-логики отвечают

Общая архитектура .NET-приложений Слой бизнес-логики (BLL) обычно включает следующие компоненты: Компоненты бизнес-логики
за извлечение, обработку, преобразование и управление данными приложения; применение бизнес-правил и политик и обеспечение непротиворечивости и актуальность данных. Чтобы создать наилучшие условия для переиспользования, компоненты BLL не должны содержать поведения или логики приложения конкретного варианта использования или пользовательской истории

Слайд 32

Общая архитектура .NET-приложений

Компоненты бизнес-логики можно подразделить на две категории:
Компоненты бизнес-процесса. После

Общая архитектура .NET-приложений Компоненты бизнес-логики можно подразделить на две категории: Компоненты бизнес-процесса.
того, как компоненты UI получили необходимые данные от пользователя и передали их в BLL, приложение может использовать эти данные для осуществления бизнес-процесса. Большинство бизнес-процессов включают множество упорядоченных этапов, которые могут взаимодействовать друг с другом через различные механизмы координирования. Компоненты определяют и координируют долгосрочные бизнес-процессы и могут быть реализованы с помощью различных инструментов. Они работают с компонентами бизнес-процесса, которые создают экземпляры и осуществляют операции с компонентами рабочего процесса

Слайд 33

Общая архитектура .NET-приложений

Компоненты бизнес-логики можно подразделить на две категории:
Компоненты бизнес-объектов инкапсулируют

Общая архитектура .NET-приложений Компоненты бизнес-логики можно подразделить на две категории: Компоненты бизнес-объектов
бизнес-логику и данные, необходимые для представления в приложении объектов реального мира, таких как заказчики (Customers) или заказы (Orders). Они хранят значения данных и предоставляют их через свойства; содержат бизнес-данные приложения и управляют ими; предоставляют программный доступ с сохранением состояния к бизнес-данным и связанной функциональности. Бизнес-объекты также проверяют данные, содержащиеся в сущности; они инкапсулируют бизнес-логику для обеспечения непротиворечивости данных, а также реализации бизнес-правил и поведения.

Слайд 34

Общая архитектура .NET-приложений

При проектировании BLL стоит задача максимально упростить приложение путем разделения

Общая архитектура .NET-приложений При проектировании BLL стоит задача максимально упростить приложение путем
задач на разные функциональные области
Например, логика обработки бизнес-правил, бизнес-процессов и бизнес-объектов – все они представляют разные функциональные области
В рамках каждой области проектируемые компоненты должны быть сфокусированы на решении конкретной задачи и не должны включать код, связанный с другими функциональными областями.

Слайд 35

Общая архитектура .NET-приложений

Основные паттерны проектирования для BLL организованы по категориям и представлены

Общая архитектура .NET-приложений Основные паттерны проектирования для BLL организованы по категориям и
далее
Компоненты BLL обычно строят с применением паттернов:
Application Façade (Фасад приложения), централизующий и агрегирующий поведение для обеспечения унифицированного слоя сервисов
Chain of Responsibility (Цепочка обязанностей) устраняет возможность связывания отправителя запроса с его получателем
Command (Команда) инкапсулирует обработку запроса в отдельный командный объект с общим интерфейсом выполнения

Слайд 36

Общая архитектура .NET-приложений

Компоненты бизнес-объектов обычно строят с применением паттернов:
Domain Model (Модель предметной

Общая архитектура .NET-приложений Компоненты бизнес-объектов обычно строят с применением паттернов: Domain Model
области) - набор бизнес-объектов, представляющих сущности предметной области и отношения между ними
Entity Translator (Транслятор сущностей) - объект, преобразующий типы данных сообщения в бизнес-типы для запросов и выполняющий обратные преобразования для ответов
Table Module (Модуль таблицы) - единый компонент, реализующий бизнес-логику для всех строк таблицы или представления базы данных

Слайд 37

Общая архитектура .NET-приложений

Компоненты рабочих процессов обычно строят с применением паттернов:
Data-Driven Workflow (Управляемый

Общая архитектура .NET-приложений Компоненты рабочих процессов обычно строят с применением паттернов: Data-Driven
данными рабочий процесс) - включает задачи, последовательность выполнения которых определяется значениями данных
Human Workflow (Рабочий процесс, управляемый оператором) включает задачи, выполняемые вручную
Sequential Workflow (Последовательный рабочий процесс) включает задачи, выполняющиеся в определенной последовательности, когда выполнение одной задачи запускается после завершения предыдущей
State-Driven Workflow (Управляемый состоянием рабочий процесс) включает задачи, последовательность выполнения которых определяется состоянием системы

Слайд 38

Общая архитектура .NET-приложений

Компоненты рабочих процессов обычно строят с применением паттернов:
Data-Driven Workflow (Управляемый

Общая архитектура .NET-приложений Компоненты рабочих процессов обычно строят с применением паттернов: Data-Driven
данными рабочий процесс) - включает задачи, последовательность выполнения которых определяется значениями данных
Human Workflow (Рабочий процесс, управляемый оператором) включает задачи, выполняемые вручную
Sequential Workflow (Последовательный рабочий процесс) включает задачи, выполняющиеся в определенной последовательности, когда выполнение одной задачи запускается после завершения предыдущей
State-Driven Workflow (Управляемый состоянием рабочий процесс) включает задачи, последовательность выполнения которых определяется состоянием системы

Слайд 39

Общая архитектура .NET-приложений

То, какие компоненты BLL будут использоваться для обработки запросов, определяет

Общая архитектура .NET-приложений То, какие компоненты BLL будут использоваться для обработки запросов,
общий дизайн и тип создаваемого приложения
Например, компоненты BLL Web-приложения обычно работают с основанными на сообщениях запросами
Приложение Windows Forms обычно взаимодействует с компонентами BLL напрямую с помощью основанных на событиях запросов
Кроме того, существуют и другие факторы, которые необходимо учесть при работе с разными типами приложений

Слайд 40

Общая архитектура .NET-приложений

Некоторые из этих факторов являются общими для различных типов, тогда

Общая архитектура .NET-приложений Некоторые из этих факторов являются общими для различных типов,
как некоторые характерны лишь для конкретного типа приложений
Рассмотрим ключевые решения, которые должны быть приняты при проектировании компонентов BLL
Компоненты BLL будут размещаться на клиенте, на сервере приложений или и там, и там?

Слайд 41

Общая архитектура .NET-приложений

Часть или все компоненты BLL размещаются на клиенте, если создается

Общая архитектура .NET-приложений Часть или все компоненты BLL размещаются на клиенте, если
изолированный насыщенный клиент или RIA-приложение, если хочется улучшить производительность, либо если используется модель предметной области
Часть или все компоненты BLL размещаются на сервере приложений, если общая бизнес-логика должна поддерживать множество типов клиентов, если компоненты BLL требуют доступа к ресурсам, недоступным с клиента, или по соображениям безопасности

Слайд 42

Общая архитектура .NET-приложений

Если компоненты BLL и PresentationLayer размещаются на одном уровне, то

Общая архитектура .NET-приложений Если компоненты BLL и PresentationLayer размещаются на одном уровне,
нужно использовать компонентные взаимодействия через события и методы
Это обеспечивает максимальную производительность

Слайд 43

Общая архитектура .NET-приложений

Однако: реализуется интерфейс сервиса и используется взаимодействие посредством обмена сообщениями

Общая архитектура .NET-приложений Однако: реализуется интерфейс сервиса и используется взаимодействие посредством обмена
между слоем представления и компонентами BLL, если его компоненты и Web-сервер располагаются на разных уровнях;
Или если разрабатывается Web-приложение со слабым связыванием между слоем представления и BLL;
Или при наличии насыщенного клиента или приложения RIA

Слайд 44

Общая архитектура .NET-приложений

Если насыщенное клиентское приложение или RIA подключаются к серверу приложений

Общая архитектура .NET-приложений Если насыщенное клиентское приложение или RIA подключаются к серверу
или Web-серверу лишь изредка, необходимо внимательно подойти к вопросу проектирования интерфейса сервиса, который должен обеспечивать повторную синхронизацию клиента при подключении

Слайд 45

Общая архитектура .NET-приложений

Бизнес-объекты хранят значения данных и предоставляют их через свойства
Они содержат

Общая архитектура .NET-приложений Бизнес-объекты хранят значения данных и предоставляют их через свойства
и управляют бизнес-данными, которые используются приложением, и обеспечивают программный доступ с сохранением состояния к бизнес-данным и связанной функциональности

Слайд 46

Общая архитектура .NET-приложений

Бизнес-объекты также должны проводить проверку содержащихся в них данных и

Общая архитектура .NET-приложений Бизнес-объекты также должны проводить проверку содержащихся в них данных
инкапсулировать бизнес-логику для обеспечения непротиворечивости и реализации бизнес-правил и необходимого поведения
Таким образом, правильное проектирование или выбор бизнес-объектов жизненно важны для обеспечения наилучшей производительности и эффективности BLL

Слайд 47

Общая архитектура .NET-приложений

Существуют различные способы представления бизнес-объектов
У каждого из них есть свои

Общая архитектура .NET-приложений Существуют различные способы представления бизнес-объектов У каждого из них
преимущества и недостатки
Перечислим наиболее распространенные форматы:
Собственные бизнес-объекты
DataSet или DataTable
XML

Слайд 48

Общая архитектура .NET-приложений

Собственные бизнес-объекты – это объекты общеязыковой среды выполнения (CLR), описывающие

Общая архитектура .NET-приложений Собственные бизнес-объекты – это объекты общеязыковой среды выполнения (CLR),
сущности системы
Для создания этих объектов может использоваться технология объектно-реляционного проецирования (O/RM), такая как ADO.NET Entity Framework (EF) или NHibernate, или их можно создавать вручную

Слайд 49

Общая архитектура .NET-приложений

Собственные бизнес-объекты подходят в случаях, когда требуется инкапсулировать сложные бизнес-правила

Общая архитектура .NET-приложений Собственные бизнес-объекты подходят в случаях, когда требуется инкапсулировать сложные
или поведение вместе со связанными с ними данными
Если требуется выполнять доступ к бизнес-объектам через границы AppDomain (Домен приложения), процесса или физические границы, можно реализовать слой сервисов, который будет обеспечивать доступ посредством объектов передачи данных (DTO) и операций обновления или редактирования бизнес-объектов

Слайд 50

Общая архитектура .NET-приложений

Объекты DataSet – это разновидность БД в памяти, которая обычно

Общая архитектура .NET-приложений Объекты DataSet – это разновидность БД в памяти, которая
очень близко соответствует фактической схеме БД
Объекты DataSet, как правило, используются только, если не используется механизм O/RM и создается объектно-ориентированное приложение, в котором данные логики приложения очень близко соответствуют схеме БД

Слайд 51

Общая архитектура .NET-приложений

DataSet не может расширяться для инкапсуляции бизнес-логики или бизнес-правил
Несмотря на

Общая архитектура .NET-приложений DataSet не может расширяться для инкапсуляции бизнес-логики или бизнес-правил
то, что DataSet могут быть сериализованы в XML, к ним не должен предоставляться доступ через границы процесса или сервиса

Слайд 52

Общая архитектура .NET-приложений

XML - это основанный на стандартах формат для организации структурированных

Общая архитектура .NET-приложений XML - это основанный на стандартах формат для организации
данных
XML обычно используется для представления бизнес-объектов, только если этого требует слой представления, или если логика должна работать с содержимым, исходя из его схемы
Например, система маршрутизации сообщений, логика которой направляет сообщения на основании некоторых известных элементов XML-документа
Использование и обработка XML может требовать больших объемов памяти.

Слайд 53

Общая архитектура .NET-приложений

Если принято решение о том, что собственные объекты обеспечат наилучшее

Общая архитектура .NET-приложений Если принято решение о том, что собственные объекты обеспечат
представление бизнес-объектов, следующим шагом является проектирование этих объектов
Подход, применяемый к проектированию собственных объектов, зависит от сорта объекта, который планируется использовать
Например, сущности модели предметной области требуют глубокого анализа предметной области, тогда как сущности модуля таблицы требуют понимания схемы БД

Слайд 54

Общая архитектура .NET-приложений

Рассмотрим общие подходы к проектированию при использовании бизнес-объектов
Модель предметной области

Общая архитектура .NET-приложений Рассмотрим общие подходы к проектированию при использовании бизнес-объектов Модель
(Domain Model) – объектно-ориентированный паттерн проектирования
Цель проектирования – определение бизнес-объектов, которые представляют реальные сущности предметной области
Бизнес-объекты и сущности предметной области включают и поведение, и структуру
Иначе говоря, бизнес-правила и отношения инкапсулированы в модели предметной области

Слайд 55

Общая архитектура .NET-приложений

Проектирование предметной области требует глубокого анализа предметной области и, как

Общая архитектура .NET-приложений Проектирование предметной области требует глубокого анализа предметной области и,
правило, не сопоставляется с реляционными моделями, используемыми большинством БД
Эту модель принято применять, если предметная область содержит сложные бизнес-правила или создается насыщенный клиент, и модель может инициализироваться и удерживаться в памяти
Модель предметной области не может применяться при работе с BLL, не сохраняющим состояние, который требует инициализации модели предметной области при каждом запросе

Слайд 56

Общая архитектура .NET-приложений

Модуль таблицы (Table Module) – это объектно-ориентированный паттерн проектирования
Цель проектирования

Общая архитектура .NET-приложений Модуль таблицы (Table Module) – это объектно-ориентированный паттерн проектирования
модуля таблицы – определение сущностей на основании таблиц или представлений базы данных
Операции, используемые для доступа к базе данных и заполнения сущностей модуля таблицы, обычно инкапсулированы в сущности

Слайд 57

Общая архитектура .NET-приложений

Однако для осуществления операций с базой данных и заполнения сущностей

Общая архитектура .NET-приложений Однако для осуществления операций с базой данных и заполнения
модуля таблицы могут также использоваться компоненты доступа к данным
Модуль таблицы применяется, если таблицы или представления базы данных достаточно точно представляют бизнес-объекты, используемые приложением, или если бизнес-логика и операции касаются одной таблицы или представления

Слайд 58

Общая архитектура .NET-приложений

Специальные XML-объекты (Custom XML objects) представляют десериализованные XML-данные, которые могут

Общая архитектура .NET-приложений Специальные XML-объекты (Custom XML objects) представляют десериализованные XML-данные, которые
обрабатываться кодом приложения
Объекты являются экземплярами классов, определяемыми атрибутами, которые сопоставляют свойства классов с элементами и атрибутами XML-структуры
.NET Framework предоставляет компоненты, которые могут использоваться для десериализации XML-данных в объекты и сериализации объектов в XML

Слайд 59

Общая архитектура .NET-приложений

Этот подход рекомендуется использовать:
если данные уже поступают в XML-формате (например,

Общая архитектура .NET-приложений Этот подход рекомендуется использовать: если данные уже поступают в
XML-файлы или операции базы данных, возвращающие XML как результирующее множество);
если требуется формировать XML-данные из источника не ХML-данных;
или при работе с документами, доступными только для чтения.

Слайд 60

Общая архитектура .NET-приложений

Слой доступа к данным может включать следующие компоненты:
Компоненты доступа

Общая архитектура .NET-приложений Слой доступа к данным может включать следующие компоненты: Компоненты
к данным
Агенты сервисов
Компоненты доступа к данным абстрагируют логику, необходимую для доступа к базовым хранилищам данных
Они обеспечивают централизацию общей функциональности доступа к данным, что способствует упрощению настройки и обслуживания приложения

Слайд 61

Общая архитектура .NET-приложений

Некоторые инфраструктуры доступа к данным могут требовать, чтобы общая логика

Общая архитектура .NET-приложений Некоторые инфраструктуры доступа к данным могут требовать, чтобы общая
доступа к данным была определена и реализована в отдельных вспомогательных или служебных компонентах доступа к данным, пригодных для повторного использования
Другие инфраструктуры доступа к данным, включая многие инфраструктуры O/RM, реализуют такие компоненты автоматически, сокращая объем кода доступа к данным, который должен написать разработчик

Слайд 62

Общая архитектура .NET-приложений

Если компонент BLL должен выполнять доступ к данным от внешнего

Общая архитектура .NET-приложений Если компонент BLL должен выполнять доступ к данным от
сервиса, может понадобиться реализовать код управления семантикой взаимодействия с этим конкретным сервисом
Агенты сервисов реализуют компоненты доступа к данным, которые изолируют меняющиеся требования вызова сервисов от приложения и могут обеспечивать дополнительные сервисы, такие как кэширование, поддержку работы в автономном режиме и базовое преобразование между форматом данных, предоставляемых сервисом, и форматом, поддерживаемым приложением

Слайд 63

Общая архитектура .NET-приложений

При выборе технологии доступа к данным необходимо учесть тип данных,

Общая архитектура .NET-приложений При выборе технологии доступа к данным необходимо учесть тип
с которыми предполагается работать, и то, как эти данные будут обрабатываться в приложении
Для каждого конкретного сценария есть наиболее подходящие технологии
Чтобы правильно выбрать технологию доступа к данным, соответствующую сценариям создаваемого приложения, можно руководствоваться следующими рекомендациями

Слайд 64

Общая архитектура .NET-приложений

ADO.NET Entity Framework (EF) можно использовать:
когда нужно создать модель данных

Общая архитектура .NET-приложений ADO.NET Entity Framework (EF) можно использовать: когда нужно создать
и соотнести ее с реляционной БД;
соотнести один класс с множеством таблиц, используя наследование;
или выполнять запросы к реляционным хранилищам, не входящим в семейство продуктов Microsoft SQL Server

Слайд 65

Общая архитектура .NET-приложений

ADO.NET Data Services построена на базе EF и позволяет предоставлять

Общая архитектура .NET-приложений ADO.NET Data Services построена на базе EF и позволяет
части модели сущностей (Entity Model) через REST-интерфейс
Эту технлогию можно использовать, если разрабатывается RIA или n-уровневое насыщенное клиентское приложение и требуется обеспечить доступ к данным через ресурсно-ориентированный интерфейс сервиса

Слайд 66

Общая архитектура .NET-приложений

ADO.NET Core используется:
если для обеспечения полного управления доступом к данным

Общая архитектура .NET-приложений ADO.NET Core используется: если для обеспечения полного управления доступом
в приложении необходим низкоуровневый API;
если нужно использовать уже сделанные инвестиции в ADO.NET-решения;
если используется традиционную логику доступа к данным.
если нет необходимости в дополнительной функциональности, как в других технологиях, или если приложение должно поддерживать сценарии доступа к данным без постоянного подключения

Слайд 67

Общая архитектура .NET-приложений

Рекомендуется использовать ADO.NET Sync Services при проектировании приложения, которое должно

Общая архитектура .NET-приложений Рекомендуется использовать ADO.NET Sync Services при проектировании приложения, которое
поддерживать сценарии без постоянного подключения или требует синхронизации БД
Если приложение работает с XML-данными, запросы к которым необходимо выполнять, применяя синтаксис LINQ, рекомендуется использовать LINQ to XML

Слайд 68

Общая архитектура .NET-приложений

При предоставлении доступа к функциональности приложения через сервисы функции сервиса

Общая архитектура .NET-приложений При предоставлении доступа к функциональности приложения через сервисы функции
должны быть выделены в отдельный слой сервисов
В слое сервисов определяется и реализуется интерфейс сервиса и контракты данных (или типы сообщений)
Одним из самых важных моментов, о котором нельзя забывать, является то, что сервис никогда не должен раскрывать детали внутренних процессов или бизнес-объектов, используемых в приложении

Слайд 69

Общая архитектура .NET-приложений

В частности, необходимо гарантировать, что сущности BLL не будут оказывать

Общая архитектура .NET-приложений В частности, необходимо гарантировать, что сущности BLL не будут
большого влияния на контракты данных
Слой сервисов должен предоставлять компоненты-трансляторы, которые будут обеспечивать преобразование форматов данных между сущностями BLL и контрактами данных
На следующем слайде показано место слоя сервисов в общей архитектуре приложения

Слайд 70

Общая архитектура .NET-приложений

Общая архитектура .NET-приложений

Слайд 71

Общая архитектура .NET-приложений

Слой сервисов обычно включает следующие компоненты:
Интерфейсы сервисов. Сервисы предоставляют

Общая архитектура .NET-приложений Слой сервисов обычно включает следующие компоненты: Интерфейсы сервисов. Сервисы
интерфейсы, в которые передаются все входящие сообщения. Интерфейс сервиса можно рассматривать как фасад, предоставляющий потенциальным потребителям доступ к BLL
Типы сообщений. При обмене данными через слой сервисов структуры данных заключаются в структуры сообщений, поддерживающие разные типы операций. Туда же обычно включают типы и контракты данных, которые определяют используемые в сообщениях типы данных

Слайд 72

Общая архитектура .NET-приложений

При проектировании слоя сервисов необходимо учесть множество факторов
Многие из этих

Общая архитектура .NET-приложений При проектировании слоя сервисов необходимо учесть множество факторов Многие
аспектов проектирования касаются проверенных практик, имеющих отношение к созданию многослойных архитектур
Однако для сервисов необходимо рассматривать также и факторы, связанные с обменом сообщениями

Слайд 73

Общая архитектура .NET-приложений

Основное, на что требуется обратить внимание: сервисы взаимодействуют посредством обмена

Общая архитектура .NET-приложений Основное, на что требуется обратить внимание: сервисы взаимодействуют посредством
сообщениями, как правило, по сети, что по сути своей медленнее, чем прямое взаимодействие внутри процесса, и обычно сервисы взаимодействуют с потребителями асинхронно
Сообщения могут быть маршрутизированы, изменены, доставлены не в том порядке, в котором они отправлялись, или потеряны, если не реализован механизм гарантированной доставки
Все это требует архитектуры, где будет учтен такой недетерминированный обмен сообщениями

Слайд 74

Общая архитектура .NET-приложений

При проектировании интерфейсов сервисов используются следующие паттерны проектирования:
Façade (Фасад) реализует

Общая архитектура .NET-приложений При проектировании интерфейсов сервисов используются следующие паттерны проектирования: Façade
унифицированный интерфейс для набора операций, чтобы обеспечить упрощенный интерфейс и уменьшить связанность систем

Слайд 75

Общая архитектура .NET-приложений

При проектировании интерфейсов сервисов используются следующие паттерны проектирования:
Remote Façade (Удаленный

Общая архитектура .NET-приложений При проектировании интерфейсов сервисов используются следующие паттерны проектирования: Remote
фасад) создает обобщенный унифицированный интерфейс для набора операций или процессов в удаленной подсистеме, обеспечивая слабо детализированный интерфейс для детализированных операций, чтобы упростить использование этой подсистемы и свести до минимума вызовы по сети

Слайд 76

Общая архитектура .NET-приложений

При проектировании интерфейсов сервисов используются следующие паттерны проектирования:
Service Interface (Интерфейс

Общая архитектура .NET-приложений При проектировании интерфейсов сервисов используются следующие паттерны проектирования: Service
сервиса) может использоваться другими системами для взаимодействия с сервисом

Слайд 77

Общая архитектура .NET-приложений

Microsoft предлагает две технологии обмена сообщениями: Windows Communication Foundation (WCF)

Общая архитектура .NET-приложений Microsoft предлагает две технологии обмена сообщениями: Windows Communication Foundation
и ASP.NET Web Services (ASMX)
WCF обеспечивает полноценный механизм реализации сервисов для широкого диапазона ситуаций и обеспечивает возможность точного регулирования конфигурации и содержимого сервисов

Слайд 78

Общая архитектура .NET-приложений

WCF подходит в следующих случаях:
Для взаимодействия с Веб-сервисами, когда

Общая архитектура .NET-приложений WCF подходит в следующих случаях: Для взаимодействия с Веб-сервисами,
необходимо обеспечить возможность взаимодействия с другими платформами, которые также поддерживают SOAP
Для взаимодействия с Веб-сервисами, использующими не SOAP-сообщения, например, приложениями, работающими с такими форматами, как Really Simple Syndication (RSS).
Для взаимодействия посредством SOAP-сообщений и двоичного кодирования для структур данных, когда и сервер, и клиент используют WCF
Для создания сервисов REST Singleton и Collection Services, ATOM Feed и Publishing Protocol Services, а также HTTP Plain XML Services

Слайд 79

Общая архитектура .NET-приложений

ASMX обеспечивает более простое решение для создания Веб-сервисов на базе

Общая архитектура .NET-приложений ASMX обеспечивает более простое решение для создания Веб-сервисов на
ASP.NET и их предоставления через Веб-сервер IIS. ASMX имеет следующие характеристики:
Обеспечивает возможность доступа через Интернет с использованием только протокола HTTP. По умолчанию использует порт 80, но изменить это не составляет никакого труда
Не поддерживает транзакций координатора распределенных транзакций (DTC). Для программирования длительных транзакций необходимо использовать собственные реализации

Слайд 80

Общая архитектура .NET-приложений

ASMX обеспечивает более простое решение для создания Веб-сервисов на базе

Общая архитектура .NET-приложений ASMX обеспечивает более простое решение для создания Веб-сервисов на
ASP.NET и их предоставления через Веб-сервер IIS. ASMX имеет следующие характеристики:
Поддерживает аутентификацию IIS, роли, хранящиеся как группы Windows для авторизации, олицетворение IIS и ASP.NET и безопасность на транспортном уровне с использованием протокола SSL
Поддерживает технологию конечных точек, реализованную в IIS
Обеспечивает возможность межплатформенного взаимодействия
Имя файла: Архитектура-NET-приложений.pptx
Количество просмотров: 274
Количество скачиваний: 0