Я оглядываюсь и вижу несколько отличных фрагментов кода для определения правил, проверки, бизнес-объектов (сущностей) и тому подобного, но должен признать, что никогда не видел отличного и хорошо написанного бизнес-уровня в целом.
Я остаюсь, зная, что мне не нравится, но не знаю, что лучше.
Может ли кто-нибудь указать на несколько хороших объектно-ориентированных бизнес-уровней (или отличных бизнес-объектов) или сообщить мне, как они оценивают бизнес-уровень и что делает его отличным?
Спасибо
Хорошие бизнес-уровни были разработаны после тщательного анализа предметной области. Если вы можете зафиксировать семантику бизнеса и изолировать ее от любого вида реализации, будь то хранилище данных или какое-либо конкретное приложение (включая представление), тогда логика должна быть хорошо продумана и повторно использована в разных контекстах.
Так же, как хороший дизайн схемы базы данных должен улавливать бизнес-семантику и изолировать себя от любого приложения, бизнес-уровень должен делать то же самое, и даже если схема базы данных и бизнес-уровень описывают одни и те же сущности и концепции, они должны использоваться в разных контекстах. - схема базы данных не должна изменяться даже при изменении бизнес-логики, если только схема не отражает текущий бизнес. Бизнес-уровень должен работать с любой схемой хранилища при условии, что он абстрагируется через промежуточный уровень. Например, инфраструктура ADO.NET Entity позволяет создавать концептуальную схему, которая сопоставляется с бизнес-уровнем и имеет отдельное сопоставление со схемой хранения, которая может быть изменена без перекомпиляции уровня бизнес-объекта или концептуального уровня. .
Если человек, занимающийся бизнесом, может взглянуть на код, написанный с помощью бизнес-уровня, и иметь приблизительное представление о том, что происходит, то это может быть хорошим признаком того, что объекты были спроектированы правильно - вы успешно передали решение в проблемную область, не запутывая ее артефактами из области решения.
Я никогда не встречал хорошо написанного бизнес-слоя.
Вот мнение Алекса Пападимулиса по этому поводу:
[...] Если задуматься, практически каждая строка кода в программном приложении - это бизнес-логика:
- Таблица базы данных клиентов с ее столбцами CustomerNumber (CHAR-13), ApprovedDate (DATETIME) и SalesRepName (VARCHAR-35): бизнес-логика. В противном случае это была бы просто Table032 с Column01, Column02 и Column03.
- Подпрограмма, которая предоставляет десятипроцентную скидку для новых клиентов: определенно бизнес-логика. И, надеюсь, не с программным кодом.
- И код, выделяющий просроченные счета красным цветом: это тоже бизнес-логика. Internet Explorer, конечно же, не ищет строки «неоплачиваемый» и «30+ дней» и пойдет, эй, это точно будет хорошо смотреться с фоном №990000!
Так как же тогда можно инкапсулировать всю эту бизнес-логику на одном уровне кода? Конечно, с ужасной архитектурой и плохим кодом!
[...] Подразумевая, что архитектура системы должна включать уровень, посвященный бизнес-логике, многие разработчики используют всевозможные ужасно хитрые методы для достижения этой цели. И это всегда заканчивается катастрофой.
Я полагаю, это потому, что бизнес-логика, как правило, произвольна и неприятна. Мусор на входе, мусор на выходе.
Кроме того, большинство действительно хороших бизнес-уровней, скорее всего, являются проприетарными. ;-)
Я всегда застревал между камнем и наковальней. В идеале ваша бизнес-логика вообще не будет связана с проблемами, связанными с базой данных или пользовательским интерфейсом.
Ключи вызывают проблемы. Тем не менее, я считаю, что такие вещи, как первичные и внешние ключи, вызывают проблемы. Даже такие инструменты, как Entity Framework, не устраняют полностью эту ползучесть. Преобразование идентификаторов, переданных в виде данных POST, в соответствующие объекты может быть крайне неэффективным, только для передачи их на бизнес-уровень, который затем передает их на уровень данных, чтобы снова их просто урезать.
Даже с базами данных NoSQL возникают проблемы. Они, как правило, возвращают полные объектные модели, но обычно возвращают больше, чем вам нужно, и могут привести к проблемам, поскольку вы предполагаете, что объектная модель не изменится. И ключи до сих пор находятся в базах данных NoSQL.
Повторное использование против накладных расходов. Существует также проблема повторного использования кода. Слои данных довольно часто возвращают полностью заполненные объекты, включая каждый столбец в этой конкретной таблице или таблицах. Однако часто бизнес-логика заботится только об ограниченном подмножестве этой информации. Он поддается специализированным объектам передачи данных, которые несут с собой только соответствующие данные. Конечно, вам нужно конвертировать между представлениями, поэтому вы создаете класс сопоставления. Затем, когда вы сохраняете, вам нужно каким-то образом преобразовать эти меньшие объекты обратно в полное представление базы данных или выполнить частичное ОБНОВЛЕНИЕ (то есть другую команду SQL).
Итак, я вижу множество классов бизнес-уровня, принимающих объекты, отображаемые непосредственно в таблицы базы данных (объекты передачи данных). Я также вижу, что многие бизнес-уровни также принимают необработанные значения пользовательского интерфейса (объекты представления). Также нет ничего необычного в том, что бизнес-уровни обращаются к базе данных в середине вычислений для получения необходимых данных. Пытаться получить его заранее, вероятно, будет неэффективно (подумайте о том, как if-statement может повлиять на извлекаемые данные), а ленивые загруженные значения приводят к большому количеству волшебных или непреднамеренных обращений к базе данных.
Сначала напишите свою логику. Недавно я пытался сначала написать "основной" код. Это код, который выполняет фактическую бизнес-логику. Не знаю, как вы, но много раз, просматривая чужой код, я задаю вопрос: «Но где это [бизнес-правило]?» Часто бизнес-логика настолько переполнена заботами о захвате данных, их преобразовании и так далее, что я даже не могу их увидеть (иголка в стоге сена). Итак, теперь я сначала реализую логику, и когда я выясняю, какие данные мне нужны, я добавляю их как параметр или добавляю их к объекту параметра. Приведение остальной части кода в соответствие с этим новым интерфейсом обычно приходится на какой-то посреднический класс.
Однако, как я уже сказал, вы должны помнить о многом при написании бизнес-уровней, в том числе о производительности. Вышеупомянутый подход был полезен в последнее время, потому что у меня еще нет прав на управление версиями или схему базы данных. Я работаю в темной комнате только со своим пониманием требований.
Пишите с тестированием в уме. Использование внедрения зависимостей может быть полезно для предварительного проектирования хорошей архитектуры. Попробуйте подумать о том, как бы вы протестировали свой код, не обращаясь к базе данных или другой службе. Это также позволяет создавать небольшие повторно используемые классы, которые могут работать в разных контекстах.
Заключение Я пришел к выводу, что на самом деле не существует идеального бизнес-уровня. Даже в одном приложении могут быть случаи, когда один подход работает только в 90% случаев. Лучшее, что мы можем сделать, это попытаться написать самое простое, что работает. Долгое время я избегал DTO и оборачивал ADO.NET DataRows объектами, чтобы обновления немедленно записывались в базовый DataTable. Это была ОГРОМНАЯ ошибка, потому что я не мог копировать объекты, а из-за ограничений в странные моменты возникали исключения. Я сделал это только для того, чтобы не указывать значения параметров явно.
Мартин Фаулер много писал о DSL в блоге. Я бы порекомендовал начать с этого места.
http://martinfowler.com/bliki/dsl.html
Мне было полезно изучить и поиграть с CSLA.Net (если вы парень MS). Я никогда не реализовывал "чистое" приложение CSLA, но использовал многие идеи, представленные в архитектуре.
Лучше всего продолжать искать эту неуловимую волшебную пулю и использовать идеи, которые лучше всего подходят для решаемой проблемы. Будь проще.
Одна проблема, которую я обнаружил, заключается в том, что даже когда у вас есть хорошо спроектированный бизнес-уровень, трудно предотвратить утечку бизнес-логики, и инструменты разработки, как правило, поощряют это. Например, как только вы добавляете элемент управления валидатором в веб-форму ASP.NET, вы позволяете бизнес-логике просачиваться в представление. Проверка должна происходить на бизнес-уровне, и в представлении должны отображаться только ее результаты. И как только вы добавляете ограничения в базу данных, у вас также появляется бизнес-логика в вашей базе данных. Тем не менее, администраторы баз данных, как правило, категорически не согласны с этим последним пунктом.
Я тоже. Мы не создаем бизнес-уровень в наших приложениях. Вместо этого мы используем MVC-ARS. Бизнес-логика встроена в конечный автомат (S) и действие (A).
Возможно, потому, что на самом деле мы никогда не сможем полностью отделить бизнес-логику от «процесса», входов, выходов, интерфейса, и что в конечном итоге людям трудно иметь дело с абстрактным, не говоря уже о том, чтобы связать его с реальностью.
