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