Бизнес-логика — в разработке информационных систем — совокупность правил, принципов, зависимостей поведения объектов предметной области (области человеческой деятельности, которую система поддерживает). Иначе можно сказать, что бизнес-логика — это реализация правил и ограничений автоматизируемых операций. Является синонимом термина «логика предметной области».
Проще говоря, бизнес-логика — это реализация предметной области в информационной системе. К ней относятся, например, формулы расчёта ежемесячных выплат по ссудам (в финансовой индустрии), автоматизированная отправка сообщений электронной почты руководителю проекта по окончании выполнения частей задания всеми подчиненными (в системах управления проектами), отказ от отеля при отмене рейса авиакомпанией (в туристическом бизнесе) и т. д.
В фазе бизнес-моделирования и разработки требований бизнес-логика может описываться в виде:
— концептуальных аналитических моделей предметной области;
— графов и диаграмм перехода состояний;
В фазе анализа и проектирования системы бизнес-логика воплощается в различных диаграммах языка UML или ему подобных. В фазе программирования бизнес-логика воплощается в коде классов и их методов, в случае использования объектно-ориентированных языков программирования, или процедур и функций, в случае применения процедурных языков.
На жаргоне разработчиков программного обеспечения «бизнес-логикой» также называются программные модули, её реализующие, и уровень системы, на котором эти модули находятся.
В многоуровневых (многослойных) информационных системах этот уровень взаимодействует с нижележащим уровнем инфраструктурных сервисов, например, интерфейсом доступа к базе данных или файловой системе и вышележащим уровнем сервисов приложения, который уже, в свою очередь, взаимодействует с уровнем пользовательского интерфейса или внешними системами.
Обобщенный алгоритм показан на рисунке 5.1, алгоритм добавления показан на рисунке 5.2, алгоритм удаления показан на рисунке 5.3.
Рисунок 5.1 – Обобщенный алгоритм программы
Описание обобщенного алгоритма:
1. При запуске программы происходит инициализация приложения и его интерфейса;
2. Ожидание нажатия кнопки интерфейса пользователем;
3. При выборе кнопки, действие которой соответствует функции добавления записи, открывается форма для добавления новой записи. Ожидается заполнение пользователем всех полей формы и нажатием кнопки «Добавить». По нажатию кнопки «Выход» форма закрывается без внесения изменений в БД;
4. При выборе кнопки, действие которой соответствует функции редактирования записи, открывается форма для редактирования выбранной записи. Ожидается внесение изменений пользователем в требуемые поля формы и нажатием кнопки «Редактировать». По нажатию кнопки «Выход» форма закрывается без внесения изменений в БД;
5. При выборе кнопки, действие которой соответствует функции удаления записи, открывается форма для удаления новой записи. Выбранная пользователем запись удаляется из БД. По нажатию кнопки «Выход» форма закрывается без внесения изменений в БД;
6. При нажатии клавиши «Сформировать отчет» происходит формирование списка данных.
7. При нажатии клавиши «Обновить» текущий список.
8. При нажатии кнопки «Выход» на главной форме, происходит закрытие приложения.
Рисунок 5.2 – Алгоритм добавления
1. Загрузка и инициализация формы и её компонентов;
2. Ожидание ввода пользователем данных в поля формы;
3. Ожидание нажатия пользователем кнопки «Продать»;
4. Проверка заполнения полей для данных. Если заполнены не все поля, то выдаётся сообщение об ошибке и происходит возврат в пункт 2, иначе происходит добавление новой записи;
5. Добавление записи.
6. Очистка полей для ввода
Рисунок 5.3 – Алгоритм удаления
1. Загрузка и инициализация формы и её компонентов;
2. Ожидание выбора пользователем данных для удаления;
3. Ожидание нажатия пользователем кнопки «Удалить»;
4. Проверка заполнения поля для данных. Если поле для удаления не выбрано, то выдаётся сообщение об ошибке и происходит возврат в пункт 2, иначе происходит удаление записи;
5. Если запись выбрана. То она будет удалена.
РУКОВОДСТВО ПОЛЬЗОВАТЕЛЯ
Назначение программы
Программа предназначена для автоматизации доступа, обработки, вывода информации реализованных билетах железнодорожной кассы. Программа имеет приятный для пользователя интерфейс (Рисунок 6.1.1).
Рисунок 6.1.1 – Интерфейс программы
Источник: cyberpedia.su
Как не допустить свалки в Django-проекте: MTV, services.py, новые приложения
Привет! Меня зовут Илья Осипов, я методист курса программирования на Python «Девман» и больше пяти лет пишу код на этом языке. В этом материале мы обсудим концепции и типовые ошибки, которые превращают утончённые и «правильные» проекты в заросли и свалки.
Когда вскрывается проблема
Представьте, вы пишете проект на Django в команде из пяти человек. На старте все замотивированы «сделать хорошо», ведь это шанс сделать проект «идеальным» с самого начала. Но проходит год или два, проект обрастает парой десятков тысяч строк кода. Разрабатывать становится всё сложнее: файлы ломятся от кода, навигироваться по проекту без продвинутых инструментов из IDE просто невозможно.
В этот момент разработчики обычно говорят, что причина возрастающей сложности — рост проекта. Или грешат на «коллег-говнокодеров» / «плохой фреймворк». Хотя с ростом проекта навигация действительно естественным образом усложняется, чаще всего виноваты отнюдь не фреймворки или количество строчек, а плохие решения.
Основная цель фреймворка — задать «фреймы», то есть «границы», в рамках которых будет работать программист. Для этого внутри Django предусмотрено множество механизмов, и многие из них описаны в документации. Некоторые — прямо в исходниках фреймворка. А какие-то детали разработчики Django не предусмотрели, и программистам приходится придумывать новые границы самостоятельно.
Зачем нужны эти границы? Разве без них не лучше?
Ответ на этот вопрос сходу поймёт любой пользователь фреймворка: не лучше. Границы пусть и создают дополнительные «препятствия», но взамен они обеспечивают понятное пространство для работы: сюда писать такой код, а сюда – вот такой, и всё будет работать. Не нужно каждый раз «изобретать велосипед» и пытаться придумать, как будет работать ваш сайт. За вас уже подумали и оставили «места для дописывания кода». Вот эти места для вашего кода — это и есть фреймы.
Архитектура MTV
Самый «высокоуровневый» фрейм в Django — это архитектурное разделение логики на Model, View и Template.
Да, архитектура Django называется именно MTV, а не MVT. Разработчики используют в документации именно такую аббревиатуру. По сути, архитектура почти полностью повторяет другой подход — MVC, Model-View-Controller (Модель-Представление-Контроллер).
- в Model хранят данные сервиса;
- View отвечает за отображение данных пользователю;
- Controller отвечает за то, чтобы сообщать Model, когда пора менять данные.
В Django же отошли от этой концепции и использовали архитектуру Model, View и Template. Сами разработчики Django пишут, что не видят никакого конфликта с MVC. Model по-прежнему отвечает за хранение данных и работу с ними. View — за «отображение» данных. Просто этот слой они разделили на два: View отвечает за то, чтобы решить, какие данные отображать, а Template — как отображать. Куда делся Controller из MVC?
В аббревиатуре MTV он пропал.
Разработчики считают, что это сам фреймворк.
Возможно, вы хотите спросить, зачем я об этом рассказываю. Разве возможно накосячить на этом уровне? Вообще-то, да.
Бизнес-логика, или слой Services
Многие разработчики пытаются переизобрести MTV и добавляют в Django дополнительный слой: Services. Вы найдёте файл serivces.py во многих туториалах и видео по Django.
Необходимость добавления этого слоя обычно объясняют так:
- В моём проекте появились функции, которые не укладываются ни в Model, ни во View;
- Я хочу сделать «бизнес-логику» реюзабельной между приложениями, и, чтобы не импортировать функции из одного View в другой, храню их отдельно.
Эти проблемы действительно существуют. Зачастую в проекте появляются вспомогательные функции, которые не принадлежат стандартным сущностям Django, вроде Model или View.
Но решение складывать весь этот код в файл services.py, на мой взгляд, плохое. Вот почему:
Слой Services слишком широкий, это плохая рамка. При определении рамок важно не определить, какой код можно класть в этот файл, а решить, какой код в этот файл класть нельзя. Для сравнения, Model хорошо справляется с этой задачей: если код не относится к работе с БД, то ему не место в файле models.py. А в services.py часто кладут всё, что не влезло в остальные.
Файл становится свалкой. Это ожидаемое следствие плохой рамки. Я часто интересуюсь у друзей и у кандидатов на собеседованиях, есть ли в их текущих или прошлых проектах такая проблема: в services.py более 2 тысяч строк кода и по нему тяжело навигироваться. Если в проекте более 10 тысяч строчек кода, разработчики почти единогласно говорят, что файл превращается в свалку.
Файл размывает слой View. Есть мнение, что в файл services.py нужно выносить бизнес-логику. Термин «бизнес-логика» кажется конкретным — это всё, что определяется правилами бизнеса. Но на поверку он размыт куда сильнее, чем кажется. Разработчики, глядя на функцию, иногда не могут сказать, бизнес-логика это или нет.
Куда девать общий код?
Альтернативное решение — оставить фреймворк в покое и не добавлять в него новый слой. Если появилась новая логика, то создать файл с говорящим названием и положить код в него. Если логики вынести нужно много — создайте несколько файлов. Искать нужную функциональность проще в одном мегафайле на тысячу строк или в пяти небольших по двести строк? Так будет куда понятнее, где, например, искать функцию, которая форматирует дату или преобразует цену товара:
Писать запросы в слое View — это нормально
Я так и не разобрался, откуда взялся миф о том, что во View нельзя писать запросы в БД, и в чём аргументация его сторонников. Это правило просто откуда-то «взялось», и теперь в него верят как в аксиому.
Тем не менее в документации Django для слоя View очень простое определение:
The view itself contains whatever arbitrary logic is necessary to return response.
Соответственно, в этом слое можно делать ORM-запросы, если это нужно для ответа. Не обязательно пытаться «прятать» этот код куда-то ещё.
Часть запросов будут нести бизнес-смысл, то есть они станут частью бизнес-логики. Иногда это будет даже не один запрос в БД, а несколько, или даже пара строк кода между ними.
По принципу MVC «Fat models, skinny controllers, simple views», большую часть такого кода стоит стараться класть в слой Model. Один из самых недооценённых, на мой взгляд, способов — переопределение QuerySet. Этот способ позволяет взять здоровый запрос на 10 вызовов методов ORM и дать ему простое, бизнесовое название.
Со слоем Services получается «Skinny Models, Skinny Controllers, Fat Services». На мой взгляд, это очевидное отхождение от принципов, которые изначально закладывались в фреймворк.
Приложения (app)
Сейчас эпоха популярности микросервисов над монолитами. Из-за этого сама архитектура Django-монолита стигматезируется, некоторые мои знакомые даже не пытаются пилить Django-монолиты на приложения. Но ведь «монолит» не равно «свалка»! За ним всё ещё стоит ухаживать.
Это будет шокирующей мыслью для многих читателей, но дробление на микросервисы на всегда оправдано (если посмотрели и заинтересовались докладом, советую ещё этот доклад).
Приложения — это следующий уровень абстракции в фреймворке, который тоже отвечает за разделение кода на кучки, но уже по другому признаку.
Можно представить, что MTV разделяет код на «красное», «синее» и «зелёное», а приложения — это разделение на «круглое», «квадратное» и «треугольное». Важное правило в делении логики на приложения — Cohesion and Coupling. Если коротко, это о связности между приложениями: нужно добиваться состояния, когда у вас мало связей между приложениями и много внутри них.
Вот к этому нужно стремиться:
Картинку взял из всё той же статьи
Между «разделёнными группами» связей мало, почти все связи спрятались внутри групп. Кружочки одного цвета — это части кодовой базы, которые сильно связаны друг с другом.
А вот такого стоит избегать:
В первом случае связи хороши, но связанный код разбросан между «приложениями». Придётся часто заходить в разные приложения, чтобы внести правку в логику «жёлтых кусочков кода», например.
Справа совсем всё плохо: код разделён на такие маленькие группы, что каждый кусочек кода сам по себе стал «группой». Это называется ‘Destructive decoupling’.
Чтобы не попасть в одну из ситуаций выше, логику приложения нужно группировать по юзкейсам, а не по сущностям. Часто эти два способа дают одинаковые результаты, но так происходит не всегда.
Когда вы группируете логику в приложения, в первую очередь смотрите, какая логика постоянно совместно используется. Переводя в идею про Cohesion and Coupling — какие из кружочков связаны большим количеством стрелочек.
Если смотреть на разделение по приложениям так, то, если потянуть за одну функцию, за ней подтянутся и другие, сильно с ней связанные. Иногда часть связей этих функций будет неожиданной, хотя будет казаться, что складывать их вместе «нелогично».
В такой ситуации советую задуматься: а почему они оказались связанными? Может, вы неправильно выбрали название для приложения и оно должно включать в себя больше.
Не стесняйтесь создавать новые приложения.
Что делать, если одна модель не помещается ни в одно из приложений? Создайте для неё отдельное!
А что, так можно? В целом ПРИЛОЖЕНИИ будет всего одна жалкая моделька?!
Да, можно. Даже нужно.
Лучше создавать приложение сразу, как только стало заметно, что оно понадобится. Ведь когда у вас наберётся много логики, разбросанной по разным приложениям, будет уже поздно.
Процесс выделения этой логики в новое приложение будет болезненным, и, делая это, вы будете задаваться вопросом: «какой м**ак раскидал эту логику по приложениям?».
Очевидно, слишком увлекаться тоже не стоит. Иначе столкнётесь с Destructive decoupling. Но и бояться создания приложений не нужно.
Файлы
Ещё один слой разделения логики по фреймворкам — это файл. Мы касались темы файлов выше, давайте резюмируем уже сказанное:
- Свалка в файлах вредит навигации по проекту.
- Cohesion and Coupling поможет разложить логику по файлам.
- Не стесняйтесь создавать файлы, даже если кода внутри будет мало. Это поможет потом не страдать, выкорчёвывая функции из кода.
- Название файла должно задавать чёткую однозначную границу, говорить о том, какому коду здесь не рады. Иначе свалки не миновать.
На третьей мысли хочется остановиться подробнее. Страх создания файлов зачастую иррационален. У разработчиков редко бывает страх создания новой функции: если это нужно, вы без проблем вынесете кусок логики в новый, небольшой «контейнер» — функцию.
С файлами аналогично, это тоже контейнер для кода. Просто функции хранят в себе строчки кода, а файлы хранят в себе функции.
У ситуации «переборщили с количеством файлов» есть надёжный симптом — читая интересующий код, вы не задерживаетесь в одном файле больше, чем на 30 секунд. Всё время приходится двигаться по файлам туда-сюда. А это и есть нарушение принципа Cohesion and Coupling.
Итоги
Если во время чтения статьи вы успели потерять основные тезисы, то вот небольшой конспект.
- Services – не часть MTV;
- Плохое название файла приведёт к свалке;
- Можно писать запросы в слое View, не бойтесь этой практики;
- Монолит – не повод сваливать всё в кучу;
- Группировать по юзкейсам лучше, чем по сущностям;
- Не стесняйтесь создавать новые файлы и приложения, даже если кода в них мало;
- Разложить логику по файлам поможет Cohesion and Coupling.
Источник: tproger.ru
Home
Качество программного обеспечения всегда было одним из «больных вопросов» для пользователей и для разработчиков. Кого ни спроси, все обязательно борются за качество. Что характерно, многие действительно борются, применяя тестирование продукта, инспекции кода, детальное документирование процесса разработки и т.д. и т.п.
Но это следовало бы назвать обеспечением качества постфактум, закономерно приводящим к необходимости борьбы с дефектами. Однако качество — это, прежде всего, соответствие программного изделия решаемой задаче. Обеспечивать качество можно и нужно путем обеспечения этого соответствия в течение всего процесса разработки. В этом случае есть шанс минимизировать количество дефектов, с которыми придется бороться.
Для иллюстрации рассмотрим возможности обеспечения качества за счет организации прикладной функциональности программной системы. Совокупность реализуемых прикладных функций также называют логикой предметной области или бизнес-логикой.
Организация кода, реализующего бизнес-логику, влияет на такие свойства программной системы, как расширяемость, открытость, сложность поддержки. Возможность вносить изменения в программную систему в разумные сроки и за разумные средства часто оказывается важным потребительским свойством системы. При этом вопросы организации программного кода зачастую не считаются достаточно важными, чтобы посвящать им специальные усилия архитектора (если таковой на проекте имеется), и отдаются на откуп программистам. Что отнюдь не сказывается благоприятным образом на качестве создаваемой системы.
Рассмотрим вопрос рационального выбора варианта организации бизнес-логики. Наша основная цель — научиться избегать грубых ошибок за счет применения простой схемы выбора варианта.
Как мы выбираем?
«Святая простота»
Распространенный способ выбора организации функциональности выглядит примерно следующим образом: «Почему так сделал?» — «Не знаю. я так привык. ». Такой способ можно назвать «святая простота», так как выбор, в сущности, ничем не обоснован. Такая ситуация обычно складывается, если от программистов требуется, чтобы это хоть как-то заработало, а обоснованием никто не интересуется.
Проблемы такого подхода очевидны. Потребительские качества программного продукта оказываются зависящими от квалификации того парня, которому выпало ваять структуру объектов или функций для приложения. Если процесс не контролировать должным образом, можно бесконечно бороться с ошибками и проблемами в продукте, связанными с неудачным выбором структуры программы.
«Идеологический подход»
Также распространенный, но недалеко ушедший от предыдущего способ писания программ: «Потому что правильно!». Разработчик, возможно, прочитал книгу по данной технологии и с этого момента всегда делает так, как в этой книге велено (варианты — изучил «суперуниверсальный» шаблон, скачал «рекомендуемый» пример и т.д.). Здесь личные предпочтения принимают форму твердой убежденности в «правильности» того или иного подхода.
При таком подходе проблемы возникают тогда, когда технологически красивое решение оказывается не соответствующим решаемой задаче. То есть подход может работать вполне успешно, однако бездумное следование авторитетам вовсе не гарантирует от неудачных решений и низкого качества продукта в результате.
Проблемы сознательного выбора
Вопросы организации программного кода зачастую непонятны руководителю проекта. Если «грабли» в долгосрочной перспективе менеджера не волнуют либо технологические вопросы ему вообще не интересны, то на выбор решения может элементарно не выделяться времени, как на низкоприоритетную задачу.
Другая проблема — отсутствие контроля качества решения. Вопрос организации функциональности часто оказывается в компетенции отдельного программиста, пусть даже это Ведущий Разработчик. А программисту интереснее писать код, ему хочется скорее сделать работоспособную версию, пусть «кривоватую», зато будет зримый результат! Размышления о том, как оптимально сконструировать систему, чтобы минимизировать проблемы в перспективе, плохо сочетаются с желанием немедленно кодировать то, что кажется понятным.
В результате разработчики начинают кодировать в соответствии с подходами, перечисленными выше. На крайний случай это называется «быстрое прототипирование» либо «наши ребята за один вечер любую задачу порвут на британский флаг». Впоследствии тем же ребятам приходится проявлять чудеса изобретательности, чтобы справиться с проблемами, возникающими из-за несоответствия архитектуры требованиям, предъявляемым к программной системе. За это программист получает отдельное спасибо, обычно заслуженное. И только он сам понимает реальную степень кривизны своего решения и осознает, что «если б было время подумать тогда, в самом начале. можно было бы так красиво сделать. а теперь уж не переделаешь. ». Но на следующем проекте повторяется та же история.
Попытаемся определить, как же именно можно «сделать красиво», если до начала кодирования найдется время подумать. Для этого рассмотрим типовые варианты организации бизнес-логики и предложим схему выбора варианта на основе простейших критериев.
Из чего мы выбираем
Существует множество разных подходов к описанию и реализации бизнес-логики. Можно сказать, что у каждого коллектива разработчиков так или иначе формируется свой подход, что выражается в методах проектирования структуры приложения, правилах кодирования и т.д.
Однако все чаще предпринимаются попытки систематизации и классификации подходов к проектированию для описания профессионального опыта в этой области. Один из способов систематизации приемов и методов проектирования структуры программных систем — шаблоны проектирования или шаблоны архитектуры (также называемые в русском переводе «паттернами», от англ. pattern — образец, модель, шаблон) [1], [2]. В частности, существует три типовых подхода к организации бизнес-логики, называемых сценарий транзакции, модель предметной области и модуль таблицы. Данные подходы в деталях рассмотрены в [1] (вплоть до фрагментов программного кода). Здесь мы рассмотрим основные особенности этих типовых решений и на их примере сформулируем соображения по выбору варианта организации бизнес-логики для проектируемой системы.
Сценарий транзакции (функциональный подход)
Это простейший подход к описанию бизнес-логики. За термином «сценарий транзакции» кроется функция системы, реализующая определенную функцию прикладной логики. Пример — расчет стоимости заказа, формируемого в системе.
При таком подходе программная система представляет собой набор функций, в котором каждая функция соответствует операции, которую приложение выполняет для пользователя. Это старая добрая процедурная модель, хорошо известная разработчикам. Проектируется иерархия функций, возможно повторное использование функций нижних уровней. Существуют давно и хорошо отработанные методологии, а также стандарты функционального моделирования, с помощью которых можно проектировать функциональную структуру программной системы в сложных случаях.
Несомненное достоинство подхода — простота реализации в программном коде. Этот вариант по плечу каждому программисту, включая новичка, едва освоившего свой первый язык программирования. Однако у функционального подхода есть и определенные недостатки.
С возрастанием сложности прикладной логики становится чрезвычайно сложно формировать структуру, не содержащую дублированных функций. А попытка переделать имеющуюся сложную структуру при изменении прикладной логики быстро приводит к тому, что функциональная структура превращается в «помойку» и выходит из-под контроля разработчиков. Все это, в конечном счете, осложняет развитие и поддержку системы.
Модель предметной области (объектный подход)
Этот подход наиболее сложен в реализации, но и наиболее продуктивен. Разрабатывается объектная модель предметной области — по крайней мере, для основных понятий. Например, для интернет-магазина могут быть созданы объекты «клиент», «товар», «корзина», «заказ» и т.д.
Вместо того, чтобы помещать бизнес-логику расчета стоимости в одну или несколько процедур, для каждого объекта реализуется функциональность исходя из зоны ответственности этого объекта. Например, объект «заказ» содержит алгоритм вычисления стоимости заказа на основе цен входящих в него товаров, при этом алгоритмы определения цен на товары реализуются отдельно, в объектах «товар». Если для разных товаров применяются разные алгоритмы вычисления цены, это достаточно легко реализовать в модели за счет создания разных типов товаров.
Достоинством модели предметной области традиционно признается гибкость. Объектный подход предоставляет в распоряжение разработчика множество способов моделирования отношений и распределения ответственности между объектами, что позволяет настраивать бизнес-логику в очень широких пределах. Кроме того, важной особенностью объектного подхода является то, что объекты могут близко соответствовать понятиям прикладной области, что в принципе позволяет разработчику и заказчику «говорить на одном языке».
Еще одним доводом в пользу объектного моделирования является то, что подавляющее большинство типовых решений — шаблонов проектирования — создано именно для применения в объектной модели. Шаблоны позволяют разрабатывать объектные структуры с заданными свойствами. В частности, создатели шаблонов уделяют значительное внимание последствиям применения шаблонов и возможностям внесения изменений в объектные структуры, предлагаемые шаблонами.
Однако за все приходится платить. В случае объектного подхода за исключительную гибкость приходится платить необходимостью выработки определенного, своеобразного стиля мышления. Новичкам приходится затрачивать много времени даже на то, чтобы разобраться в имеющейся объектной структуре (например, в шаблоне), не говоря уже о самостоятельном проектировании объектной структуры. Не всем удается преодолеть барьер освоения этой технологии; многие разработчики, даже работая на объектно-ориентированном языке и применяя объектные библиотеки, фактически используют процедурный стиль программирования.
Другая особенность модели предметной области — необходимость создания сложных программных механизмов взаимодействия объектных структур с реляционными базами данных. Разработка такого механизма обычно обходится дорого (хотя на этот счет тоже имеются типовые решения), и это, конечно, не упрощает жизнь в случае применения объектной модели.
Модуль таблицы (смешанный подход)
Перечисленные выше методы организации бизнес-логики представляют собой два «крайних» случая. Третий случай — смешанный, гибридный подход, сочетающий в себе определенные достоинства (и недостатки) функционального и объектного подходов.
Типовое решение «модуль таблицы» предусматривает, как и в модели предметной области, отдельные объекты для товаров, заказов и т.д. Однако, в отличие от «настоящей» модели предметной области, в модуле таблицы для работы со всеми (к примеру) заказами, содержащимися в базе данных, применяется только один объект. Именно этот единственный объект содержит логику обработки заказов. А чтобы работать с отдельным заказом, следует указывать его уникальный идентификатор.
Перечитайте предыдущий абзац.
Вас не пугает то, что в нем написано? И вам все понятно? Тогда, скорее всего, для вас не будет иметь значения недостаток данного подхода — сложность разработки и сложность восприятия кода. С точки зрения прозрачности, читабельности кода модуль таблицы заметно проигрывает «настоящей» модели предметной области (конечно, предполагается, что разработчик в каждом случае использует максимум возможностей сделать код простым и понятным). При несложной логике предметной области модуль таблицы проигрывает в простоте реализации и функциональному подходу.
Основные преимущества модуля таблицы — простота взаимодействия с базой данных и гибкость структурирования бизнес-логики по сравнению с функциональным подходом. Возможно также применение шаблонов проектирования. Однако по сравнению с моделью предметной области гибкость и возможности применения шаблонов в модуле таблицы существенно ограничены.
Целесообразность применения модуля таблицы также зависит от уровня поддержки структуры множества записей в конкретной среде разработки (включая удобство отображения множества записей на базу данных и на элементы графического интерфейса). Развитая поддержка набора данных ( DataSet ) в среде Microsoft . Net во многих случаях оправдывает применение этой платформы разработки.
Что мы выбираем
Особенности подходов
Перечислим основные особенности рассмотренных типовых решений, позволяющие сравнивать эти решения между собой и выбирать подход, соответствующий задаче.
Сценарий транзакции (функциональный подход) : предельно прост, плохо работает при сложной логике, затрудняет развитие системы.
Модель предметной области (объектный подход) : наиболее сложный и затратный, позволяет реализовать сложную бизнес-логику, дает возможность «цивилизованно» развивать систему; для простых систем подход целесообразен, только если уже «обкатан» разработчиком.
Модуль таблицы (смешанный подход) : обеспечивает определенное сочетание простоты и гибкости, однако гибкость ограничена, а эффективность подхода зависит от среды разработки.
На основе рассмотренных особенностей можно сформулировать несколько критериев и предложить упрощенную схему выбора подхода на основе качественной оценки критериев.
Качественные критерии и схема выбора
Особенности типовых решений показывают, что решение по выбору подхода можно принять на основе качественной оценки следующих критериев:
- опыт команды разработчиков;
- стабильность бизнес-логики (ожидаемая стабильность функциональных требований);
- сложность бизнес-логики (функциональная сложность задач, решаемых программной системой);
- среда разработки (удобство работы с множеством записей).
Схема принятия решения на основе этих критериев приведена на рисунке.
Упрощенная схема выбора типового решения для реализации бизнес-логики
На схеме хорошо видно, что в некоторых случаях выбор сделать очень легко. Например, когда приложение простое, изменений не предвидится, да и с объектной моделью связываться непривычно — с чистой совестью применяем простой функциональный подход. С другой стороны, команда фанатов объектного подхода будет строить объектную модель предметной области во всех случаях — и правильно сделает (учитывая то, что такая команда вряд ли будет заниматься тривиальными проектами).
Пограничные ситуации требуют оценки стабильности и сложности разработки. На предлагаемом уровне это не должно вызвать затруднений.
Данная методика предназначена в первую очередь для оперативного «прокручивания» в голове с целью избежать грубых ошибок при выборе программного решения. Подобная систематизация также представляется полезной как первый шаг программиста к сознательному и ответственному проектированию приложений, в противоположность «проектированию на лету».
В реальных проектах, как обычно, все обстоит сложнее. Например, вопрос организации бизнес-логики может теряться на фоне массы других вопросов разработки архитектуры. Однако это не значит, что решение нужно пускать на самотек. Приведенная схема показывает, что можно предельно упростить принятие решения, не теряя при этом возможность выявить «подводные камни».
Вкратце
Решение по организации прикладной логики программной системы непосредственно влияет на качество создаваемого изделия. Это решение может и должно приниматься сознательно, исходя из требований и применяемых технологий. В идеале при выборе программного решения следует учитывать гораздо больше факторов, чем мы здесь упоминаем. Однако использование предлагаемой схемы выбора может стать первым шагом к формированию привычки выбирать обоснованное решение по организации бизнес-логики.
Существует три основных способа организации бизнес-логики программной системы: функциональный, объектный и смешанный. Каждый из способов имеет свои преимущества и недостатки, и задача разработчика — выбрать способ, оптимальный для данного проекта. В первом приближении выбор решения можно предельно упростить, однако в каждом конкретном проекте существует множество «подводных камней», для выявления которых может понадобиться весь богатый опыт «хождения по граблям». Единственное, чего не следует делать — это бездумно полагаться при выборе программной конструкции на личные пристрастия или мнения авторитетов. Начните с простых правил, применяйте проверенные шаблоны, рассматриваемые в профессиональной литературе, но в любом случае выбирайте решение самостоятельно.
Литература
- М. Фаулер. Архитектура корпоративных программных приложений. — М.: Издательский дом «Вильямс», 2006.
- Э. Гамма и др. Приемы объектно-ориентированного проектирования. Паттерны
Игорь Остроухов,
6 июля 2006 г.
Источник: www.software-testing.ru