Я никогда не сталкивался с хорошо написанным деловым слоем. Любой совет?

Question

Я осматриваюсь и вижу несколько отличных фрагментов кода для определения правил, валидации, бизнес-объектов (сущностей) и т. П., Но я должен признать, что никогда не видел великолепного и хорошо написанного бизнес-уровня во всей его полноте.

Я остаюсь, зная, что мне не нравится, но не зная, что такое великий.

Кто-нибудь может указать на некоторые хорошие ОО бизнес-уровни (или отличные бизнес-объекты) или сообщить мне, как они оценивают бизнес-уровень и что делает его великим?

Спасибо

Answer 1

Я никогда не сталкивался с хорошо написанным бизнес-уровнем.

Вот Взятие Алекса Пападимулиса об этом :

[...] Если подумать, практически каждая строка кода в программном обеспечении приложение бизнес логика:

• Таблица базы данных клиентов, с его CustomerNumber (CHAR-13), ApprovedDate (DATETIME) и Столбцы SalesRepName (VARCHAR-35): бизнес логика. Если бы не было, это было бы просто быть Table032 с Column01, Столбец02 и Столбец03.
• The подпрограмма, которая распространяется на десять процентов скидка для новых клиентов: безусловно, бизнес-логика. А также надеюсь, не с мягким кодом.
• И код, который выделяет просроченные счета в красном: это дело логика тоже. Internet Explorer конечно не ищет строки «Неоплаченный» и «30+ дней» и иди, эй, это наверняка будет хорошо смотреться с фоном # 990000!

Так как же тогда можно заключить всю эту бизнес-логику в одном слое кода? С ужасная архитектура и плохой код Конечно!

* 1032. И это всегда заканчивается катастрофой.

Answer 2

Я полагаю, это потому, что бизнес-логика, как правило, произвольна и противна. Мусор на входе, мусор на выходе.

Кроме того, большинство действительно хороших бизнес-уровней, скорее всего, являются собственностью. ; -)

Answer 3

Хорошие бизнес-уровни были разработаны после тщательного анализа предметной области. Если вы можете зафиксировать семантику бизнеса и изолировать ее от любого вида реализации, будь то в хранилище данных или в каком-либо конкретном приложении (включая представление), тогда логика должна быть хорошо продумана и повторно использоваться в различных контекстах.

Точно так же, как хороший дизайн схемы базы данных должен фиксировать бизнес-семантику и изолировать себя от любого приложения, так и бизнес-уровень должен делать то же самое, и даже если схема базы данных и бизнес-уровень описывают одни и те же сущности и концепции, они должны использоваться в отдельных контекстах - схема базы данных не должна изменяться даже при изменении бизнес-логики, если схема не отражает текущий бизнес. Бизнес-уровень должен работать с любой схемой хранения при условии, что она абстрагируется от промежуточного уровня. Например, инфраструктура ADO.NET Entity позволяет проектировать концептуальную схему, которая сопоставляется с бизнес-уровнем и имеет отдельное сопоставление со схемой хранения, которую можно изменить без перекомпиляции уровня бизнес-объекта или концептуального уровня.

Если человек с деловой стороны может взглянуть на код, написанный на бизнес-уровне, и иметь общее представление о том, что происходит, то это может быть хорошим признаком того, что объекты были спроектированы правильно - вы успешно передали решение в области задачи, не запутывая его артефактами из области решения.

Answer 4

Я всегда застрял между камнем и наковальней. В идеале ваша бизнес-логика не должна касаться проблем, связанных с базой данных или пользовательским интерфейсом.

Клавиши вызывают проблемы Тем не менее, я нахожу такие вещи, как первичные и внешние ключи, вызывающие проблемы. Даже такие инструменты, как Entity Framework, не полностью устраняют эту проблему. Преобразование идентификаторов, переданных в виде данных POST, в их соответствующие объекты может быть крайне неэффективным, только чтобы передать их на бизнес-уровень, который затем передает их на уровень данных, чтобы их снова сократили.

Даже базы данных NoSQL поставляются с проблемами. Они, как правило, возвращают полные объектные модели, но обычно возвращают больше, чем вам нужно, и могут привести к проблемам, потому что вы предполагаете, что объектная модель не изменится. И ключи все еще находятся в базах данных NoSQL.

Повторное использование против накладных расходов Существует также проблема повторного использования кода. Обычно слои данных возвращают полностью заполненные объекты, включая каждый столбец в этой конкретной таблице или таблицах. Тем не менее, часто бизнес-логика заботится только об ограниченном подмножестве этой информации. Он поддается специализированным объектам передачи данных, которые несут с собой только соответствующие данные. Конечно, вам нужно конвертировать между представлениями, поэтому вы создаете класс mapper. Затем, когда вы сохраняете, вам нужно каким-то образом преобразовать эти меньшие объекты обратно в полное представление базы данных или выполнить частичное ОБНОВЛЕНИЕ (что означает другую команду SQL).

Итак, я вижу, что многие классы бизнес-уровня принимают объекты, отображаемые непосредственно в таблицы базы данных (объекты передачи данных). Я также вижу много бизнес-уровней, принимающих необработанные значения пользовательского интерфейса (объекты презентации). Также нет ничего необычного в том, что бизнес-уровни обращаются к базе данных в середине вычислений для получения необходимых данных. Попытка получить его заранее, вероятно, будет неэффективной (подумайте о том, как и если оператор if может повлиять на извлекаемые данные), а отложенные загруженные значения приводят к множеству магических или непреднамеренных обращений к базе данных.

Сначала напишите свою логику Недавно я пытался сначала написать «основной» код. Это код, который выполняет реальную бизнес-логику. Я не знаю о вас, но много раз, просматривая чужой код, я задаю вопрос: «Но где это [бизнес-правило]?» Зачастую бизнес-логика настолько переполнена заботами о сборе данных, их преобразовании и тому подобном, что я даже не вижу их (иголка в стоге сена). Итак, теперь я сначала реализую логику и, выясняя, какие данные мне нужны, я добавляю их в качестве параметра или добавляю их в объект параметра. Получение остальной части кода для соответствия этому новому интерфейсу обычно зависит от некоторого класса-посредника.

Однако, как я уже сказал, при написании бизнес-уровней необходимо учитывать многое, в том числе производительность. Подход выше был полезен в последнее время, потому что у меня еще нет прав на контроль версий или схему базы данных. Я работаю в темной комнате, и до сих пор только понимаю требования.

Пишите с тестированием в уме Использование внедрения зависимостей может быть полезно для предварительного проектирования хорошей архитектуры. Попробуйте подумать о том, как вы будете тестировать свой код, не обращаясь к базе данных или другому сервису. Это также подходит для небольших, многократно используемых классов, которые могут работать в нескольких контекстах.

Заключение Я пришел к выводу, что идеального бизнес-уровня на самом деле не существует. Даже в одном приложении могут быть случаи, когда один подход работает только 90% времени. Лучшее, что мы можем сделать, - это написать простейшую вещь, которая работает. Долгое время я избегал DTO и обернул ADO.NET DataRows объектами, чтобы обновления сразу записывались в базовый DataTable. Это была ОГРОМНАЯ ошибка, потому что я не мог копировать объекты, и ограничения вызывали исключения в странные времена. Я сделал это только для того, чтобы явно не задавать значения параметров.

Answer 5

Мартин Фаулер много писал о DSL. Я бы порекомендовал начать там.

http://martinfowler.com/bliki/dsl.html

Answer 6

Одна проблема, которую я нахожу, состоит в том, что даже когда у вас есть хорошо продуманный бизнес-уровень, трудно остановить утечку бизнес-логики, и инструменты разработки имеют тенденцию поощрять это. Например, как только вы добавили элемент управления валидатора в ASP.NET WebForm, вы позволили бизнес-логике просочиться в представление. Проверка должна происходить на бизнес-уровне, и только результаты ее отображаются в представлении. И как только вы добавите ограничения в базу данных, в вашей базе данных появится бизнес-логика. Типы DBA, как правило, сильно не согласны с этим последним пунктом.

Answer 7

Мне было полезно учиться и играть с CSLA.Net (если вы парень из MS). Я никогда не реализовывал «чистое» приложение CSLA, но использовал многие идеи, представленные в архитектуре.

Ваш лучший выбор - продолжать искать эту неуловимую волшебную пулю и использовать идеи, которые наилучшим образом соответствуют решаемой вами проблеме. Сохраняй это простым.

Answer 8

Возможно, потому что в действительности мы никогда не в состоянии полностью отделить бизнес-логику от «процесса», входов, выходов, интерфейса, и, в конечном счете, людям трудно иметь дело с абстрактным, не говоря уже о том, чтобы вернуть его обратно к реальности.

Answer 9

Я тоже. Мы не создаем бизнес-уровень в наших приложениях. Вместо этого мы используем MVC-ARS . Бизнес-логика встроена в конечный автомат (S) и действие (A).