Я никогда не встречался с правильно написанным бизнес-слоем. Совет?
Вы можете добавить статусы в вашу таблицу.
$table->enum('create_status', ['Pending', 'Approved'])->default('Pending');
В этом случае, когда User A создал игру, create_status будет "Pending"
И вы можете вытянуть всю строку, что это create_status, это "Pending" на Сторона администратора, поэтому администратор может approved сделать это.
Также, если User A решили delete или update
Добавить столбец, например. для удаления delete_status
$table->enum('delete_status', ['Pending', 'Approved'])->default('Pending');
Тот же случай, что и create_status
Это просто идея, если у вас есть что-то лучше, сделайте это.
8 ответов
Хорошие бизнес-слои были разработаны после полного анализа предметной области. Если можно получить семантику бизнеса и изолировать ее от какого-либо вида реализации, является ли это в хранении данных или каком-либо определенном приложении (включая презентацию), то логика должна быть хорошо учтена и допускающая повторное использование в различных контекстах.
Так же, как хороший дизайн схемы базы данных должен получить бизнес-семантику и изолированный саму из любого приложения, бизнес-слой должен сделать то же и даже если схема базы данных и бизнес-слой описывают те же объекты и понятия, эти два должны быть применимыми в отдельных контекстах - схеме базы данных не придется измениться, даже когда бизнес-логика изменяется, если схема не отражает текущий бизнес. Бизнес-слой должен работать с любой схемой устройства хранения данных при условии, что это абстрагировано через intermdiate слой. Например, платформа Объекта ADO.NET позволяет Вам разработать концептуальную схему, которая отображается на бизнес-слой и имеет отдельное отображение на схему устройства хранения данных, которая может быть изменена, не перекомпилировав слой бизнес-объекта или концептуальный слой.
Если человек с бизнес-стороны вещей может посмотреть на код, написанный с бизнес-слоем, и иметь общее представление о том, что продолжается затем, это мог бы быть хороший признак, что объекты были разработаны право - Вы успешно передали решение в проблемной области, не запутывая его с артефактами от домена решения.
Я предполагаю, что это вызвано тем, что бизнес-логика, как правило, произвольна и противна. Мусор в, мусор.
Кроме того, большинство действительно хороших бизнес-слоев является по всей вероятности собственным.;-)
Я никогда не встречался с правильно написанным бизнес-слоем.
Вот Alex Papadimoulis, берут это:
[...], Если Вы думаете об этом, фактически каждая строка кода в приложении является бизнес-логикой:
- Клиентская таблица базы данных, с ее CustomerNumber (CHAR-13), ApprovedDate (ДАТА И ВРЕМЯ) и столбцы SalesRepName (VARCHAR-35): бизнес-логика. Если бы это не было, то это просто был бы Table032 с Column01, Column02 и Column03.
- Подпрограмма, которая расширяет скидку на десять процентов до первого раза клиенты: определенно бизнес-логика. И надо надеяться, не мягко кодированный.
- И код, который выделяет просроченные счета красного цвета: это - бизнес-логика, также. Internet Explorer, конечно, не ищет “неоплаченные” строки и “30 + дни” и идет, эй, который уверенный выглядел бы хорошим с фоном № 990000!
Таким образом, как затем возможно инкапсулировать всю эту бизнес-логику в единственном слое кода? С ужасной архитектурой и плохим кодом, конечно!
[...] Путем допущения, что архитектура системы должна включать слой, выделенный бизнес-логике, многие разработчики используют все виды ужасно умных методов для достижения той цели. И это всегда заканчивается в аварии.
Мне было полезно учиться и играть с CSLA.Net (если Вы - парень MS). Я никогда не реализовывал "чистое" приложение CSLA, но использовал многие идеи, представленные в архитектуре.
Ваш лучший выбор является содержанием, ища то неуловимое чудодейственное средство, и используйте идеи, которые лучше всего соответствуют проблеме, которую Вы решаете. Сохраните это простым.
Martin Fowler вел блог экстенсивно о DSLs. Я рекомендовал бы запуститься там.
Одна проблема, которую я нахожу, состоит в том, что, даже когда у Вас есть приятно разработанный бизнес-слой, трудно остановить просачивание бизнес-логики, и средства разработки имеют тенденцию поощрять это. Например, как только Вы добавляете элемент управления проверки правильности к ASP.NET WebForm, Вы позволили бизнес-логике просочиться в представление. Проверка должна произойти в бизнес-слое и только результатах отображенного в представлении. И как только Вы добавляете ограничения к базе данных, у Вас затем есть бизнес-логика в Вашей базе данных также. Типы DBA имеют тенденцию не соглашаться сильно с этой последней точкой все же.
Я тоже. Мы не создаем бизнес-слой в наших приложениях. Вместо этого мы используем MVC-ARS. Бизнес-логика встраивается в (S) конечный автомат и (A) действие.
Возможно, потому что в действительности мы так и не смогли полностью отделить бизнес-логику от "процесса", исходных данных, выводов, интерфейса и что в конечном счете людям трудно иметь дело с кратким обзором уже не говоря о связи его назад к действительности.