Бизнес-логика слоя (BLL) о данных?

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

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

Отправка электронной почты определенно не является бизнес-логикой - это довольно общее требование и определенно не специфично для вашего бизнеса или отрасли.

] BLL означает ваш уровень бизнес-логики. Она должна обрабатывать все, что связано с вашим уровнем бизнес-логики. SendEmail может быть лучше в каком-то классе утилит?[

] Также, если вы говорите в своем BLL о механизме электронной почты, вы даете ему слишком много информации (тесно связанный, следуйте закону деметра для функций, wiki / google it). Ваш BLL не заботится об электронной почте и не должен заботиться об этом. [

] Когда вы упомянули [] Данные [], вы, вероятно, остановились на DAL (Уровень доступа к данным). Это уровень, который обрабатывает вставки/обновления данных и т.д. на каком-то ресурсе, таком как база данных. [

] BLL - это не данные... это Бизнес (отсюда [] Бизнес[] Логический уровень). [

] В DAL все дело в Дейте. [

] Вероятно, я бы переместил метод SendMail в класс Utility, но совершенно законно, что вам нужно будет вызывать SendMail из BLL. [

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

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

Здесь происходят две «неправильные» вещи и два способа их исправить.

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

Во-вторых, правило «! -d» специально избегает перезаписи, которую вы хотите сделать, если на самом деле существует каталог с таким именем

Решение 1: вручную повторно маршрутизировать запросы для каталога портфеля, чтобы удалить косую черту.

# Manually re-route portfolio/ requests to portfolio
RewriteCond %{REQUEST_FILENAME} portfolio/$
RewriteRule ^(.*)/$ $1 

# Hide extension
RewriteCond %{REQUEST_FILENAME}\.html -f
RewriteRule ^(.*)$ $1.html

Обратите внимание на удаление условия «! -d».

Недостатком этого является то, что вам приходится жестко кодировать «портфельный» краевой корпус непосредственно в правила перезаписи, и это все равно приведет к тому, что браузер будет сначала перенаправлен в портфолио/

Решение 2: Задайте параметр «» Выкл «» и удалите папку «» существует «» test

# Disable Automatic Directory detection
DirectorySlash Off

# Hide extension
RewriteCond %{REQUEST_FILENAME}\.html -f
RewriteRule ^(.*)$ $1.html

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

При тестировании решения 2 браузер может запомнить перенаправление «портфолио» на «портфолио/» и выполнить перенаправление до того, как он даже отправит запрос на сервер. Убедитесь, что проверка в чистом кэше позволяет получить наилучшие результаты.

Необходимо прочитать последовательность удаления из реестра с учетом AppId (т.е. значения, использованного для AppID в разделе [Setup] ). Его можно найти в разделе Программное обеспечение\Microsoft\Windows\CurrentVersion\Uninstall\{ AppId }\ (может быть либо HKLM , либо HKCU , поэтому лучше проверить оба), где {AppId} следует заменить фактическим используемым значением. Найдите значения UninstallString или QuietUninstallString и с помощью функции Exec запустите ее из функции события InitialitySetup () .

Обновление: удалено неработающее альтернативное решение с помощью записи раздела [Run] с помощью {uninstallexe} - спасибо всем комментаторам, которые указали на это!

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

Однако инициирование отправки сообщения электронной почты может исходить от уровня busines, и бизнес-уровень не должен вызывать уровень представления.

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

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