Здравствуйте, Ocenochka, Вы писали:

O> Очень хочется почитать основы, но не могу найти на русском. Чтобы подробно разжевывался этот рисунок:


В книжке вроде же всё расписано. Не понятен сам рисунок или проблема именно в русском?

Давай я попробую дать свою версию нарисованному, остальные меня поправят.

UI Components

Грубо говоря – это контролы, набросанные на форму и логика их взаимодействия. Задача этого слоя – отобразить данные и принять ввод пользователя, произвести первичную валидацию вводимых данных, проверить правильность формата и обязательность ввода определённых полей. При наличии развитого фреймворка данный слой можно свести практически к тыканью мышкой по экрану и заполнению свойств соответствующих объектов. Когда ты создаёшь в студии форму WinForms или WebForms это как раз и есть этот самый слой.

User Process Components

Фактически этот слой реализует логику обработки данных на клиенте. Обычная последовательность разработки формы выглядит следующим образом:

1. У сервера запрашиваются данные, которыми заполняется форма.
   
2. Введённые пользователем данные собираются вместе, проверяются, возможно предварительно обрабатываются и отправляются серверу (в более простых случаях, передаются напрямую слою бизнес логики).

Если теперь мы вынесем в отдельный слой всё, что не касается самой формы непосредственно, то, как раз и получим то, что понимается под данным слоем. Логика обращения к серверу, очередная, более сложная валидация данных, некоторая предварительная обработка, кеширование данных на клиенте, всё это никак не зависит от того, какой пользовательский интерфейс используется, и, следовательно, может быть повторно использовано как между различными формами так и между различными типами интерфейсов.

Service Interfaces

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

Кстати, термин фасад, который вводится в обсуждаемой книжке так в общем-то и не прижился. А жаль.

Есть в данной схеме одна небольшая нестыковочка. Если взять в качестве примера следующий интерфейс:

public interface PersonService
{
    Person GetPersonByID(int id);
}

то здесь мы увидим использование объекта Person, который относится на самом деле к Business Entities. По схеме же Business Entities у нас спрятаны за фасадом.

Business Workflows

Бизнес логика может быть простая, а может быть сложная. Что-то можно сделать в один шаг – получил, сосчитал, положил в базу данных, забыл. Что-то требует множества шагов, наличие состояний, логики переходов из одного состояния в другое и т.п.

Предположим, мы регистрируем заказ от нового заказчика. Занесение информации о заказчике в базу данных не требует сложной логики. Фамилия, адрес, рост, вес, имя любимой кошечки, всё это просто сохраняется во вновь созданном аккаунте. Но вот с самим заказом дело обстоит не так просто. Прежде чем товар дойдёт до клиента, он пройдёт через множество стадий, таких как резервирование, упаковка, оплата, отгрузка и пр. Возможно, придётся сделать дополнительную закупку у поставщиков, если товара нет на складе. А ещё возможно, что заказчик в самый последний момент захочет отменить заказ, либо же на его счету в банке элементарно не окажется денег. Вся подобная многоэтапная логика реализуется в данном слое, иногда с применением тяжелой артиллерии в виде дорогих серверов управления процессами. В частности Microsoft предлагает в качестве такого решения BizTalk Server Orchestration. А с выходом FW 3.0 мы получим бесплатное решение — WWF, по отзывам специалистов очень качественную реализацию Business Workflow.

Business Components

Собственно здесь реализуется логика приложения. Даже если используется какая-либо система управления процессами, то ей всё равно могут понадобиться компоненты, реализующие бизнес правила и выполняющие определённые бизнес задачи. Большая часть логики приложения должна реализовываться в этом слое. Но, естественно, без фанатизма. Например, вполне законным исключением могут быть толстые клиенты, которые, если используются, могут реализовывать большую часть логики. Тогда этот слой может быть частично перенесён на клианта или реализован в User Process Components. Серверная часть в этои случае превращается по сути в набор pass-throught методов. Впрочем, при согласованном дизайне можно добиться такого же и в случае с тонким клиентом.

Business Entities

Бизнес сущности, они же Domain Entities, они же Data Transfer Objects (DTO). Примитивные существа, которыми манипулируют и обмениваются между собой клиент и сервер. Обычно они представляют собой просто структуру данных, класс с набором свойств, XML сообщение. Datasets из пространства имён System.Data также относятся к бизнес сущностям, хотя и воображают себя маленькими базами данных.

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

Тем не менее, не смотря на свой примитивизм, Business Entities являются одной из важнейших частей приложения, т.к. они используются практически всеми слоями. В результате от простоты/сложности/запутанности их использования напрямую зависит простота/сложность/запутанность логики всего приложения.

Data Access Logic Components

Основное назначение данного слоя – изоляция источника данных от остальных частей приложения. Другими словами перевод языка запросов данных в термины нашего приложения.

Основная проблема связи приложения с базой данных посредством SQL заключается в том, что нам приходится работать с нетипизированными в терминах нашего приложения данными, приходящими из источника, и обращаться к ним, используя строковые имена или, в наиболее невменяемых случаях, порядковые номера. Что если нам понадобилось изменить, например, имя или тип поля любой объявленной в программе структуры? Даже если мы не приведём в соответствие остальные части приложения, то компилятор не даст нам ошибиться и покажет все места, где, по его мнению, мы не правы. В случае же с именами объектов базы данных всё совсем не так. К сожалению, здесь у нас нет такого помощника, и мы должны полагаться только на самих себя. Любые некорректные действия в данном случае не могут быть обнаружены в момент компиляции (compile time) и аукнутся нам лишь во время работы приложения (runtime). Следовательно, чем меньше у нас прямых мест обращения к базе данных и чем более они сконцентрированы в одном месте, тем меньше нас ожидает проблем в будущем при модификации и сопровождении нашего приложения.

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

Service Agents

По большому счёту эти компоненты ничем не отличаются от предыдущих. Разница лишь в том, что компоненты DAL извлекают данные из базы данных, а агенты сервисов делают то же самое по отношению к сервисам, предоставляемым нашей программе другими приложениями. Например, если нам необходимо читать данные из дружественных .NET Web сервисов или вызывать вражеские Java компоненты, то идея перевода полученных данных в формат нашего приложения вполне резонна.

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

Фактически фреймворк – это ещё одна большая и ответственная часть приложения, которая состоит не только из программных компонентов, то так же и соглашений и правил, регулирующих сам процесс разработки.

Итого. Если в выше приведённой схеме объединить серенькие квадратики в один и сделать корректировку относительно Business Entities, то можно получить немного другую, более точную и, главное!, более симметричную картинку



По-моему, стало похоже на первую версию Электроника

IT>public interface PersonService
IT>{
IT>    Person GetPersonByID(int id);
IT>}
IT>

public class PersonManager
{
    public Person GetPersonByID(int id)
    {
        return DataAccessor.GetPersonByID(id);
    }
}