Рассматривая структуру логики предметной области (или бизнес-логики) приложения, отметим, что варианты распределения множества предусматриваемых ею функций могут рассматриваться по трем типовым решениям: сценарий транзакции (TransactionScript), модель предметной области (DomainModel) и модуль таблицы (TableModule). Простейший подход к описанию бизнес-логики связан с использованием сценария транзакции — процедуры, которая получает на вход информацию от слоя представления, обрабатывает ее, проводя необходимые проверки и вычисления, сохраняет в базе данных и активизирует операции других систем. Затем процедура возвращает слою представления определенные данные, возможно, осуществляя вспомогательные операции для форматирования содержимого результата. Бизнес-логика в этом случае описывается набором процедур, по одной на каждую (составную) операцию, которую способно выполнять приложение. Типовое решение сценарий транзакции, таким образом, можно трактовать как сценарий действия, или бизнес-транзакцию. Оно не обязательно должно представлять собой единый фрагмент кода. Код делится на подпрограммы, которые распределяются между различными сценариями транзакции. Типовое решение сценарий транзакции отличается следующими преимуществами:
- представляет собой удобную процедурную модель, легко воспринимаемую всеми разработчиками;
- удачно сочетается с простыми схемами организации слоя источника данных на основе типовых решений шлюз записи данных (Row Data Gateway) и шлюз таблицы данных (Table Data Gateway);
- определяет четкие границы транзакции.
С возрастанием уровня сложности бизнес-логики типовое решение сценарий транзакции демонстрирует и ряд недостатков. Если нескольким транзакциям необходимо осуществлять схожие функции, возникает опасность дублирования фрагментов кода. С этим явлением удается частично справиться за счет вынесения общих подпрограмм «за скобки», но даже в этом случае большая часть дубликатов остается на месте. В итоге приложение может выглядеть как беспорядочная мешанина без отчетливой структуры. Конечно, сложная логика — это удачный повод вспомнить об объектах, и объектноориентированный вариант решения проблемы связан с использованием модели предметной области, которая, по меньшей мере в первом приближении, структурируется преимущественно вокруг основных сущностей рассматриваемого домена. Так, например, в лизинговой системе следовало бы создать классы, представляющие сущности «аренда», «имущество», «договор» и т.д., и предусмотреть логику проверок и вычислений: так, например, объект, представляющий сущность «имущество», вероятно, уместно снабдить логикой вычисления стоимости. Выбор модели предметной области в противовес сценарию транзакции — это как раз та смена парадигмы программирования, о которой так любят говорить апологеты объектного подхода. Вместо использования одной подпрограммы, несущей в себе всю логику, которая соответствует некоторому действию пользователя, каждый объект наделяется только функциями, отвечающими его природе. Если прежде вы не пользовались моделью предметной области, процесс обучения может принести немало огорчений, когда в поисках нужных функций вам придется метаться от одного класса к другому. Рассмотрим простой пример, позволяющий увидеть различие между двумя рассматриваемыми подходами. Простейший способ состоит в сопоставлении диаграмм последовательностей (sequence diagrams), соответствующих обоим вариантам решения одной проблемы (рис. 2.1 и 2.2). В задаче определения зачтенного дохода от продажи каждого продукта в рамках заданного контракта алгоритм вычислений зависит от типа продукта. Вычислительный метод должен распознать тип продукта, применить подходящий алгоритм, а затем создать соответствующий объект, представляющий значение дохода. Из рис. 2.1 видно, что все обязанности возлагаются на метод сценария транзакции, получающий данные от объектов типа шлюз таблицы данных. На рис. 2.2 показано, напротив, несколько объектов, каждый из которых несет ответственность за выполнение своей доли функций, а результат генерируется объектом «Стратегия определения зачтенного дохода». Ценность модели предметной области состоит в том, что, освоившись с подходом, вы получаете в свое распоряжение множество приемов, позволяющих поладить с возрастающей сложностью бизнес-логики «цивилизованным» путем. Например, с увеличением количества алгоритмов расчета дохода достаточно создавать новые объекты «Стратегия определения зачтенного дохода». При использовании сценария транзакции в аналогичной ситуации пришлось бы добавлять в логику метода дополнительные условия. 
Рис. 2.1. Вычисление зачтенного дохода с помощью сценария транзакции 
Рис. 2.2. Вычисление зачтенного дохода с помощью модели предметной области Существует и третий вариант структуризации бизнес-логики, предусматривающий применение типового решения модуль таблицы; он показан на рис. 2.3. На первый взгляд это типовое решение очень похоже на модель предметной области: в обоих случаях создаются отдельные классы, представляющие контракт, продукт и зачтенный доход. Принципиальное различие заключается в том, что модель предметной области содержит по одному объекту контракта для каждого контракта, зафиксированного в базе данных, а модуль таблицы является единственным объектом. Модуль таблицы применяется совместно с типовым решением множество записей (Record Set). Посылая запросы к базе данных, пользователь прежде всего формирует объект множество записей, а затем создает объект контракта, передавая ему множество записей в качестве аргумента (см. рис. 2.3). Если потребуется выполнять операции над отдельным контрактом, следует сообщить объекту соответствующий идентификатор (ID). 
Рис. 2.З. Вычисление зачтенного дохода с помощью модуля таблицы Модуль таблицы во многих смыслах представляет собой промежуточный вариант, компромиссный по отношению к сценарию транзакции и модели предметной области. Организация бизнес-логики вокруг таблиц, а не в виде прямолинейных процедур облегчает структурирование и возможность поиска и удаления повторяющихся фрагментов кода. Однако решение модуль таблицы не позволяет использовать многие технологии (скажем, наследование (inheritance), стратегии (strategies) и другие объектно-ориентированные типовые решения), которые применяются в модели предметной области для уточнения структуры логики. Наибольшее преимущество модуля таблицы состоит в том, как это решение сочетается с остальными аспектами архитектуры. Многие графические интерфейсные среды позволяют работать с результатами обработки SQL-запроса, организованными в виде множества записей. Поскольку решение модуль таблицы также основано на использовании множества записей, открывается возможность выполнения запроса, манипулирования его результатом в контексте модуля таблицы и передачи данных графическому интерфейсу для отображения. Некоторые платформы, в частности Microsoft COM и .NET, поддерживают именно такой стиль разработки.
Ограничение
Для продолжения скачивания необходимо пройти капчу:
Источник: studfile.net
Реализация бизнес-логики (LINQ to SQL)
Термин «бизнес-логика» в данном разделе относится к любым пользовательским правилам или проверкам, которые применяются к данным перед их вставкой, обновлением или удалением в базе данных. Бизнес-логику также иногда называют бизнес-правилами или логикой предметной области. В n-уровневых приложениях он обычно разработан как логический уровень, чтобы его можно было изменять независимо от уровня представления или уровня доступа к данным. Бизнес-логика может вызываться уровнем доступа к данным перед обновлением, вставкой или удалением данных в базе данных или после выполнения этих операций.
Бизнес-логика может представлять собой простую схему проверки совместимости типа поля с типом столбца таблицы. Она также может состоять из набора объектов, взаимодействующих произвольным и довольно сложным образом. Правила могут реализовываться в виде хранимых процедур для базы данных или в качестве объектов, содержащихся в памяти. Однако бизнес-логика реализована, LINQ to SQL позволяет использовать разделяемые классы и разделяемые методы, чтобы отделить бизнес-логику от кода доступа к данным.
Способы вызова бизнес-логики технологией LINQ to SQL
При создании класса сущностей во время разработки вручную или с помощью реляционный конструктор объектов или SQLMetal он определяется как разделяемый класс. Это означает, что в отдельном файле с исходным кодом можно определить другую часть этого класса сущностей, содержащего пользовательскую бизнес-логику. Во время компиляции обе части объединяются в один класс. Но если необходимо повторно создать классы сущностей с помощью реляционный конструктор объектов или SQLMetal, это можно сделать, и ваша часть класса не будет изменена.
Разделяемые классы, которые определяют сущности, и класс DataContext содержат разделяемые методы. Эти методы являются точками расширения, которые можно использовать для применения бизнес-логики перед обновлением, вставкой или удалением сущности или свойства сущности, а также после выполнения этих операций. Разделяемые методы можно рассматривать как события времени компиляции. Генератор кода определяет сигнатуру метода и вызывает эти методы в методах доступа к свойствам «get» и «set», конструкторе DataContext и в некоторых случаях неявным образом при вызове метода SubmitChanges. Однако, если не реализовать определенный разделяемый метод, все ссылки на него и определение удаляются во время компиляции.
В определении реализации, созданном в отдельном файле с исходным кодом, можно выполнить любую требуемую пользовательскую логику. Можно использовать разделяемый класс в качестве уровня домена или вызывать его из определения реализации разделяемого метода в отдельном объекте или объектах. В любом случае бизнес-логика полностью отделена как от кода уровня доступа к данным, так и от кода уровня представления данных.
Более подробное рассмотрение точек расширения
В следующем примере показана часть кода, созданная реляционный конструктор объектов для DataContext класса, имеющего две таблицы: Customers и Orders . Обратите внимание, что методы «Insert», «Update» и «Delete» определены для каждой таблицы в классе.
Partial Public Class Northwnd Inherits System.Data.Linq.DataContext Private Shared mappingSource As _ System.Data.Linq.Mapping.MappingSource = New _ AttributeMappingSource #Region «Extensibility Method Definitions» Partial Private Sub OnCreated() End Sub Partial Private Sub InsertCustomer(instance As Customer) End Sub Partial Private Sub UpdateCustomer(instance As Customer) End Sub Partial Private Sub DeleteCustomer(instance As Customer) End Sub Partial Private Sub InsertOrder(instance As [Order]) End Sub Partial Private Sub UpdateOrder(instance As [Order]) End Sub Partial Private Sub DeleteOrder(instance As [Order]) End Sub #End Region
public partial class MyNorthWindDataContext : System.Data.Linq.DataContext < private static System.Data.Linq.Mapping.MappingSource mappingSource = new AttributeMappingSource(); #region Extensibility Method Definitions partial void OnCreated(); partial void InsertCustomer(Customer instance); partial void UpdateCustomer(Customer instance); partial void DeleteCustomer(Customer instance); partial void InsertOrder(Order instance); partial void UpdateOrder(Order instance); partial void DeleteOrder(Order instance); #endregion
При реализации методов Insert, Update и Delete в разделяемом классе среда выполнения LINQ to SQL будет вызывать их вместо собственных методов по умолчанию при SubmitChanges вызове . Это позволяет переопределить поведение, реализуемое по умолчанию для операций создания, чтения, обновления и удаления. Дополнительные сведения см. в разделе Пошаговое руководство. Настройка поведения вставки, обновления и удаления классов сущностей.
Метод OnCreated вызывается в классе конструктора.
Public Sub New(ByVal connection As String) MyBase.New(connection, mappingSource) OnCreated() End Sub
public MyNorthWindDataContext(string connection) : base(connection, mappingSource)
Классы сущностей имеют три метода, которые вызываются средой выполнения LINQ to SQL при создании, загрузке и проверке сущности (при SubmitChanges вызове). Классы сущностей также имеют два разделяемых метода для каждого свойства. Один метод вызывается перед заданием свойства, а другой — после. В следующем примере кода демонстрируются некоторые методы, созданные для класса Customer .
#Region «Extensibility Method Definitions» Partial Private Sub OnLoaded() End Sub Partial Private Sub OnValidate(action As _ System.Data.Linq.ChangeAction) End Sub Partial Private Sub OnCreated() End Sub Partial Private Sub OnCustomerIDChanging(value As String) End Sub Partial Private Sub OnCustomerIDChanged() End Sub Partial Private Sub OnCompanyNameChanging(value As String) End Sub Partial Private Sub OnCompanyNameChanged() End Sub ‘ . Additional Changing/Changed methods for each property.
#region Extensibility Method Definitions partial void OnLoaded(); partial void OnValidate(); partial void OnCreated(); partial void OnCustomerIDChanging(string value); partial void OnCustomerIDChanged(); partial void OnCompanyNameChanging(string value); partial void OnCompanyNameChanged(); // . additional Changing/Changed methods for each property
Эти методы вызывается в методе доступа «set» для свойства, как показано в следующем примере для свойства CustomerID :
Public Property CustomerID() As String Set If (String.Equals(Me._CustomerID, value) = False) Then Me.OnCustomerIDChanging(value) Me.SendPropertyChanging() Me._CustomerID = value Me.SendPropertyChanged(«CustomerID») Me.OnCustomerIDChanged() End If End Set End Property
public string CustomerID < set < if ((this._CustomerID != value)) < this.OnCustomerIDChanging(value); this.SendPropertyChanging(); this._CustomerID = value; this.SendPropertyChanged(«CustomerID»); this.OnCustomerIDChanged(); >> >
В пользовательской части класса создается определение реализации метода. В Visual Studio после ввода partial вы увидите IntelliSense для определений методов в другой части класса.
Partial Public Class Customer Private Sub OnCustomerIDChanging(value As String) ‘ Perform custom validation logic here. End Sub End Class
partial class Customer < partial void OnCustomerIDChanging(string value) < //Perform custom validation logic here. >>
Дополнительные сведения о добавлении бизнес-логики в приложение с помощью разделяемых методов см. в следующих разделах.
См. также
- Разделяемые классы и методы
- Разделяемые методы
- Средства LINQ to SQL в Visual Studio
- SqlMetal.exe (средство создания кода)
Источник: learn.microsoft.com
КРАТКИЙ КОНСПЕКТ книги
«Архитектура корпоративных приложений» Мартин Фаулер
Приступая к разработке корпоративного приложения важно определить, какой из трех вариантов организации логики предметной области целесообразно применить в конкретной ситуации . 1) сценарий транзакции (Transaction Script) Процедуры, которая получает на вход информацию от слоя представления, обрабатывает ее, проводя необходимые проверки и вычисления, сохраняет в базе данных и возвращает нужные данные слою представления. Достоинства:
— удобная процедурная модель, легко воспринимаемая всеми разработчиками;
— удачно сочетается с простыми схемами организации слоя источника данных на основе типовых решений шлюз записи данных (Row Data Gateway) и шлюз таб лицы данных (Table Data Gateway);
— определяет четкие границы транзакции. Недостатки: если некоторым транзакциям необходимо осуществлять схожие функции, возникает опасность дублирования фрагментов кода . Можно вынести дублирующиеся фрагменты кода в отдельные методы, но в итоге приложение теряет четкую структуру 2) модель предметной области (Domain Model) Процедуры, отвечающие за бизнес-логику размещаются в соответствующих объектах предметной области.
Недостатком данной модели является сложность изучения и практического применения. Аккуратное применение модели предметной области требует навыка, а небрежность здесь просто недопустима . Второй недостаток — тесная связь модели предметной области с реляционной моделью данных и сложность отображению объектов в реляционные структуры.
3) модуль таблицы (Table Module) — это объект предметной области, работающий не с отдельным объектом, а с целым массивом данных. Модуль таблицы представляет собой промежуточный вариант, компромиссный по отношению к сценарию транзакции и модели предметной области.
Организация бизнес-логики вокруг таблиц, а не в виде прямолинейных процедур облегчает структурирование и возможность поиска и удаления повторяющихся фрагментов кода. Однако решение модуль таблицы не позволяет использовать многие технологии (скажем, наследование (inheritance), стратегии (strategies) и другие объектно-ориентированные типовые решения), которые применяются в модели предметной области для уточнения структуры логики.
Применение модуля таблицы оправдано тогда, когда платформа поддерживает инфраструктуру множества записей. Какую модель выбрать? Если логика приложения проста, модель предметной области менее соблазнительна, поскольку затраты на ее реализацию не окупаются. Но с возрастанием сложности альтернативные подходы становятся все менее приемлемыми: трудоемкость пополнения приложения новыми функциями увеличивается по экспоненциальному закону. Один из общих подходов к реализации бизнес-логики состоит в расщеплении слоя предметной области на два самостоятельных слоя: «поверх» модели предметной области или модуля таблицы располагается слой служб (Service Layer), который действует как API приложения . Варианты организации слоя служб:
1) использовать слой служб в виде промежуточного интерфейса, который только и делает, что направляет адресуемые ему вызовы к нижележащим объектам . Таким образом слой обеспечивает варианты использования (use cases ) приложений и предоставляет удачную возможность включить в код функции-оболочки, ответственные за управление транзакциями и проверку безопасности .
2) в рамках слоя служб представить большую часть логики в виде сценариев транзакции. Нижележащие объекты домена в этом случае могут быть тривиальными
3) «контроллер-сущность» («controller—entity») — Главная особенность модели заключается в том, что логика, относящаяся к отдельным транзакциям или вариантам использования, располагается в соответствующих сценариях транзакции, которые в данном случае называют контроллерами (или службами)
Фаулер советует делать слой служб минимально возможным.
Источник данных
Избрав способ формирования слоя предметной области, необходимо определить, как подключить бизнес-логику к источнику данных. Принимаемые на этом этапе решения целиком зависят от типа слоя домена : 1) Источник данных для сценария транзакции можно организовать в виде шлюза записи данных или шлюза таблицы данных.
2) Источник данных для модуля таблицы : так как основной довод в пользу использования модуля таблицы может быть связан с наличием хорошей инфраструктуры множества записей, в качестве источника данных для модуля таблицы логично использовать шлюз таблицы. 3) Источник данных для модели предметной области : слабость модели предметной области во многом обусловлена усложнением аппарата взаимодействия с базой данных, и величина проблемы пропорциональна степени сложности модели.
Если модель предметной области проста , то имеет смысл прибегнуть к решению активная запись (Active Record). Несколько ослабить зависимости поможет шлюз таблицы данных или шлюз записи данных. По мере усложнения модели стоит обратиться к преобразователю данных (Data Mapper). Этот подход отвечает требованию обеспечения максимальной независимости модели предметной области от всех других слоев системы, но сложнее всего реализуется на практике.
Слой представления
Слой представления относительно независим от выбора форм реализации нижележащих слоев системы. Первый вопрос касается того, какому типу интерфейса отдать предпочтение — толстому клиенту или HTML-обозревателю.
Толстый клиент в состоянии обеспечить более привлекательную и разнообразную интерфейсную графику, но такой выбор сопряжен с дополнительными расходами по внедрению и сопровождению клиентских частей системы. В данной книге рассматриваются типовые решения из области проектирования веб-интерфейсов.
В качестве основного решения для веб-приложений Фаулер предлагает типовое решение модель—представление—контроллер (Model View Controller ). Решение во многом может быть обусловлено наличием в вашем распоряжении тех или иных инструментальных средств. Если проектируемое приложение в большей степени ориентировано на представление документов, причем в виде смеси статических и динамических Web-страниц, я рекомендовал бы контроллер страниц.
Более сложные условия навигации и повышенные требования к графическому интерфейсу предполагают использование контроллера запросов. Выбор между представлением по шаблону и представлением с преобразованием (Transform View) зависит от того, какой инструмент программирования — страницы сервера или XSLT — вы применяете. Сейчас более популярно представление по шаблону, хотя мне импонирует относительная простота тестирования, обеспечиваемая представле- нием с преобразованием. Если ваш сайт должен поддерживать возможности доступа с по- мощью разнообразных обозревателей, следует воспользоваться двухэтапным представле- нием (Two Step View). Если же вы вынуждены использовать несколько процессов, поверх слоя предметной области следует расположить интерфейс удаленного доступа (Remote Facade), а для взаимообмена информацией с Web-сервером — применять объекты переноса данных (Data Transfer Object).
Во второй части книги подробно описаны упоминаемые типовые решения, их принцип действия и назначение.
Впечатления о книге
Как и все книги Фаулера, книга насыщена полезной информацией, написана доступным языком, с исчерпывающим количеством примеров. Впрочем начинать читать эту книгу я бы посоветовала со второй части и лишь после того, как основные типовые решения станут вам знакомы, переходить к общей части первой главы. Данный конспект не затрагивает описание конкретных решений. Им будет посвящен отдельный конспект.
Источник: developer.uz
