Данная статья является продолжением поста “Программная архитектура”. Ознакомьтесь с ним перед тем, как приступить к изучению.
Простейшим архитектурным решением, является “Сценарий транзакции” (автор Мартин Фаулер). Это решение предлагает использовать несколько скриптовых сценариев, обрабатывающих запросы пользователя к системе и возвращающих ему результат этой обработки. Важным условием здесь является то, что сценарии отвечают за весь производственный цикл ответа, а не делегируют обработку другим частям приложения.
Рассмотрим несколько примеров:
<?php
// Процедурный стиль
// controller/guestbook.php
...
switch($_REQUEST['action']){
// Просмотр гостевой книги
case 'index':
$template = new Template('view/guestbook/index.php', [
'posts' => Db::getInstance()->select('SELECT * FROM `guestbook` LIMIT 10 ORDER BY `added` DESC')
]);
echo $template->render();
break;
// Добавление сообщения в гостевую книгу
case 'add':
$text = InputStringFilter($_POST['text']);
Db::getInstance()->insert('guestbook', [
'text' => $text,
'added' => time(),
]);
return header('Location: /guestbook.php?action=index');
break;
}<?php
// Объектный стиль
// controller/guestbook.php
class GuestbookController{
// Просмотр гостевой книги
public function indexAction(){
$template = new Template('view/guestbook/index.php', [
'posts' => Db::getInstance()->select('SELECT * FROM `guestbook` LIMIT 10 ORDER BY `added` DESC')
]);
return $template->render();
}
// Добавление сообщения в гостевую книгу
public function addAction(){
$text = InputStringFilter($_POST['text']);
Db::getInstance()->insert('guestbook', [
'text' => $text,
'added' => time(),
]);
return header('Location: /guestbook.php?action=index');
}
}Подобный подход чаще всего используется в небольших проектах и отличается следующими возможностями:
- Быстрая разработка, за счет исключения из архитектуры дополнительных компонентов, таких как модели, сервисы и т.д.
- Простота изучения (только до определенного момента), основанная на аккумуляции всей логики приложения в скрипты транзакций
К сожалению применение этой архитектуры в средних и крупных проектах влечет следующие проблемы:
- Дублирование кода, вызванное отсутствием гибкости архитектуры и невозможностью частичного вынесения логики из сценариев для повторного использования
- Раздувание сценариев (как следствие предыдущего пункта) и усложнение процесса их изучения
Permalink
Cannot retrieve contributors at this time
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| <!DOCTYPE HTML PUBLIC «-//W3C//DTD HTML 4.01//EN» «http://www.w3.org/TR/html4/strict.dtd»> | |
| <html> | |
| <head> | |
| <link rel=»icon» type=»image/x-icon» href=»http://design-pattern.ru/favicon.ico«> | |
| <link rel=»stylesheet» type=»text/css» href=»../css/commons.css«> | |
| <link rel=»search» type=»application/opensearchdescription+xml» title=»Поиск паттернов» href=»../search.xml«> | |
| <title>Паттерн Transaction Script — Сценнарий транзакции. Описания паттернов проектирования. Паттерны проектирования. Design pattern ru</title> <meta name=»keywords» content=»Описания паттернов проектирования, Паттерны проектирования, Design pattern ru, Паттерн Transaction Script» > <meta http-equiv=»Content-type» content=»text/html;charset=UTF-8«> | |
| </head> | |
| <body><a href=»https://github.com/design-pattern-ru/design-pattern-ru.github.io«><img style=»position: absolute; top: 0; left: 0; border: 0;» src=»https://camo.githubusercontent.com/82b228a3648bf44fc1163ef44c62fcc60081495e/68747470733a2f2f73332e616d617a6f6e6177732e636f6d2f6769746875622f726962626f6e732f666f726b6d655f6c6566745f7265645f6161303030302e706e67» alt=»Fork me on GitHub» data-canonical-src=»https://s3.amazonaws.com/github/ribbons/forkme_left_red_aa0000.png«></a> | |
| <div id=»wrapper«> | |
| <div id=»header«> | |
| <p><a href=»../index.html«>Справочник «Паттерны проектирования»</a><a style=»position:absolute» title=»design pattern в twitter» href=»http://twitter.com/design_pattern«><img title=»Твиттер воробей» alt=»паттерны проектирования на твиттере» src=»../i/twitter.png«></a></p> | |
| </div> | |
| <div id=»content«> | |
| <h1>Transaction Script <em>(Сценнарий транзакции)</em></h1> | |
| <p><img src=»../i/transaction-script.gif» alt=»Паттерн проектирования Transaction Script«></p> | |
| <p><span class=»quot«>Паттерн проектирования Transaction Script</span></p> | |
| <h2>Описание Transaction Script</h2> | |
| <p>Организует бизнес-логику в процедуры, которые управляют каждая своим запросом.</p> | |
| <p>Большинство бизнес-приложений можно представить в виде набора транзакций. Какие-то из них выбират данные, какие-то ‐ меняют. Каждое взаимодействие пользователя и системы содержит определённый набор действий. В некоторых случаях это может быть просто вывод данных из БД. В других случаях эти дествия могут содержать в себе множество вычислений и проверок.</p> | |
| <p>Паттерн <acronym title=»Паттерн Transaction Script (Сценнарий транзакции)«>Transaction Script</acronym> организует всю эту логику в одну процедуру, работая в БД напрямую или через тонкую обёртку. Каждая транзакция имеет свой <acronym title=»Паттерн Transaction Script (Сценнарий транзакции)«>Transaction Script</acronym>, хотя общие подзадачи могут быть разбиты на процедуры.</p> <p class=»note«>Использована иллюстрация с сайта <a href=»../martin-fowler.html«>Мартина Фаулера</a>.</p> <p class=»note«><noindex><a href=»http://martinfowler.com/eaaCatalog/transactionScript.html«>Источник</a></noindex></p> </div> | |
| <div style=»clear:both;margin-top: -2.5em«> </div> | |
| </div> | |
| <ul id=»footer-menu«> | |
| <li><a href=»../index.html«>Главная</a></li> | |
| <li><a href=»index.html» title=»Список шаблонов проектирования«>Список паттернов</a></li> | |
| <li>Сайт создан и поддерживается <a href=»http://kulakovvasiliy.moikrug.ru/«>Василием Кулаковым</a>.</li> | |
| </ul> | |
| <script type=»text/javascript«> | |
| var gaJsHost = ((«https:» == document.location.protocol) ? «https://ssl.» : «http://www.»); | |
| document.write(unescape(«%3Cscript src='» + gaJsHost + «google-analytics.com/ga.js’ type=’text/javascript’%3E%3C/script%3E»)); | |
| </script> | |
| <script type=»text/javascript«> | |
| try { | |
| var pageTracker = _gat._getTracker(«UA-10786597-1»); | |
| pageTracker._trackPageview(); | |
| } catch(err) {} | |
| </script><!— Yandex.Metrika counter —> | |
| <div style=»display:none;«><script type=»text/javascript«> | |
| (function(w, c) { | |
| (w[c] = w[c] || []).push(function() { | |
| try { | |
| w.yaCounter6876103 = new Ya.Metrika({id:6876103, | |
| clickmap:true, | |
| trackLinks:true, | |
| accurateTrackBounce:true}); | |
| } | |
| catch(e) { } | |
| }); | |
| })(window, ‘yandex_metrika_callbacks’); | |
| </script></div> | |
| <script src=»http://mc.yandex.ru/metrika/watch.js» type=»text/javascript» defer=»defer«></script> | |
| <noscript><div><img src=»http://mc.yandex.ru/watch/6876103» style=»position:absolute; left:-9999px;» alt=»» /></div></noscript> | |
| <!— /Yandex.Metrika counter —></body> | |
| </html> |
Архитектурные шаблоны централизованного управления
Архитектурные шаблоны централизованного управления относятся к типам шаблонов, которые предлагают централизованный способ организации логики выполняемых программных продуктов.
Паттерны этой категории содержат описание механизмов единого унифицированного управления, основанного на структурных особенностях поэтапного выполнения программ. Эти шаблоны выполняют роль «мозгового центра» проектируемого программного продукта.
Сценарий транзакций
Современные корпоративные информационные системы обладают большим количеством компонентов и громоздкой иерархической структурой их взаимосвязей.
Вызов процедур, как правило, осуществляется «сверху вниз». Управление начинается на вершине иерархии и через вызовы передается на нижние уровни.Подобный способ управления хорошо зарекомендовал себя в программных продуктах, в которых процессы запускаются и выполняются последовательно, в соответствии с условиями их функционирования.
Применение шаблона «Сценарий транзакций» способствует сохранению целостности, прозрачности, предсказуемости создаваемого программного обеспечения.»Сценарий транзакции»целесообразно рассматривать как механизм организации бизнес-логики («Модель предметной области»).
«Сценарий транзакций»– процедура, которая получает на вход информацию от слоя представления, обрабатывает ее, производя необходимые проверки и вычисления, сохраняет в базе данных и активизирует операции других слоев.
В качестве основных недостатков можно выделить сложность выявления и обработки исключительных ситуаций. Сценарий транзакции не годится для организации «запутанной»бизнес-логики.
Диспетчер
Этот шаблон организации систем предусматривает создание системного компонента, который назначается диспетчером, то есть отвечает за управление и координацию выполнения процессов, исполняемых в программном продукте. При этом нет ограничений на способы выполнения процессов («последовательно», «параллельно» и пр.).
Паттерн, как правило, применяется в системах, для которых необходимо повысить их общую производительность за счет «запараллеливания» процессов, но может использоваться и для последовательной обработки (управляющая программа или диспетчер вызывает отдельные подсистемы в зависимости от значений некоторых переменных состояния).
Одним из главных недостатков применения шаблона «Диспетчер» является рекомендация по использованию в так называемых «мягких» системах реального времени (нет строгих временных ограничений).
Применение «Диспетчера» целесообразно в тех случаях, когда группа разработки полностью понимает и имеет различные способы воздействия на все программные компоненты (система представляет собой «прозрачный» ящик).
Архитектурные шаблоны управления по событиям
Управление по событиям является способом координации потока(ов) информации и ее последующей обработки в зависимости от факторов и условий, значимых для достижений конечного результата деятельности программного приложения.
Шаблоны управления по событиям помогают в разработке логики, автоматизирующей значимые функции, возникающие при наступлении или отсутствии определенных бизнес-сигналов.
Передача сообщений
Данный шаблон проектирования транслирует каждое обрабатываемое событие в виде передачи сообщений всем заинтересованным подсистемам, которые обрабатывают событие и при необходимости отвечают на него. Шаблон «Передача сообщений» получил особую популярность при реализации систем, обрабатывающих сложную и разрозненную бизнес-логику.
Логика исполнения основана на сетевом взаимодействии различных участников автоматизируемого процесса.Сферы ответственности участников достаточно независимы друг от друга. Конечный результат обработки определяется вкладом каждого из участников.
Управление прерываниями
Шаблон «Управление прерываниями» применяется в основном в системах реального времени со строгими временными требованиями на обработку поступающих извне сообщений, когда необходима быстрая реакция системы на зафиксированное событие.
Использование данного шаблона предусматривает регистрацию возникающих прерываний специализированным обработчиком. После чего наступает стадия непосредственной обработки, которая должна выполняться другим системным компонентом.
Шаблон «Управление прерываниями» очень часто используют вместе с шаблоном «Диспетчер». В случае штатного функционирования система управляется посредством «Диспетчера», а в критических ситуациях используется управление, основанное на прерываниях. Основной недостаток подобного комбинирования шаблонов состоит в том, что система сложна в программировании и последующем тестировании. Если уделить внимание основным сложностям, то они состоят в имитации всех возможных прерываний, которые должны быть известны априори.
Join the DZone community and get the full member experience.
Join For Free
Transaction Script (TS) is the simplest domain logic pattern we can find. It needs less work to implement than other domain logic patterns and therefore it’s perfect fit for smaller applications that doesn’t need big architecture behind them. This posting focuses on TS pattern by illustrating and analysing it. Also some good hints for implementation are provided.
Definition
Transaction Script organizes business logic by procedures where each procedure handles a single request from the presentation.
pg. 110, Patterns of Enterprise Applications Architecture by Martin Fowler
Example
Imagine application that provides some functionalities:
- load orders to deliver,
- generate invoices,
- calculate bonuses for customers.
These functionalities can be handled as two transactions: generate invoices, calculate bonuses. We cań create classes to handle invoice generating and bonus calculation but we can also go with one class that provides both methods. It’s up to you to decide which is better for you.
class InvoiceGenerator
{
public void GenerateInvoices()
{
load orders to deliver
iterate through orders
generate invoice
mark them ready to deliver
}
}
This example uses one class for all operations. If you have many operations then use multiple classes to organize code better.
Where I use TS?
I have used TS mainly in small applications where I really don’t want to apply any bigger architecture. TS will save you a lot of time when applied in correct context. Some applications where I used TS are:
- Estonian ID-card based door lock control – Windows service and simple Windows Forms applications that allow to manage users, give permissions for opening doors and see who and when opened the door. It may sound like big application but the actual complexity lies in hardware and the software I wrote is actually very simple.
- Jira importer – my company uses small service that imports work logs and tasks from Jira to our main database where programming work, sales and billing meet. Getting data from Jira can be tricky but still this service is simple enough to avoid more complex patterns.
On both cases I got simple classes that provide some functionalities needed by applications and it took less time than implementing full domain model by example.
Tips
- TS works well for small applications that doesn’t implement any complex logic,
- When used in bigger applications TS has problems like code and functionalities duplication between procedures. If you see application growing then switch to some other domain logic pattern that is better fit for your application.
- It’s not easy usually to refactor TS to other domain logic patterns as other patterns deal more or less with classes that represent some business entity.
- In TS you can use different data source patterns to access and manipulate data. In my door lock control system I used ADO.NET objects. My Jira importer uses simple Entity Framework classes.
- When building your TS classes you can also apply design patterns to organize code better. Don’t let your TS classes grow to big bad spaghetti code.
- Don’t make TS classes dependent on presentation layer classes because dependencies like these makes it harder to share those classes between applications and also testing of TS classes will be very hard this way.
Wrapping up
TS is simple and lightweight domain logic pattern that is perfect fit for smaller applications that do nothing complex. It is possible to gather all operations together to one class but if you have many operations then it’s better to use more than one class for operations. If you see your application growing bigger and more complex then switch quickly to some other domain logic pattern that fits your needs better.
Related Posts
- ASP.NET MVC: Moving code from controller action to service layer
- Patterns of Enterprise Application Architecture
- Analysis Patterns: Reusable Object Models
- Some points about services layer
- Writing cache based repositories for web application prototyping
The post Transaction Script Pattern appeared first on Gunnar Peipman — Programming Blog.
application
Published at DZone with permission of Gunnar Peipman, DZone MVB.
See the original article here.
Opinions expressed by DZone contributors are their own.