Я нахожусь в уровне анти утечки уровня? Что я должен делать?

Question

Меня попросили добавить модуль в существующую систему.Изучая структуру, я обнаружил что-то «странное».Система основана на Struts1.

В некоторых jsp я обнаружил, что есть некоторые вызовы DAO для возврата объекта сущности.На большинстве страниц JSP есть тег <app:validate>, который будет вызывать DAO для проверки прав доступа и перенаправлять на страницу входа, если это не разрешено.Есть объект accessDA, но он делает не только выборку данных, но и некоторую проверку прав доступа.

Мои вопросы:

1. Приводит ли вызов DAO в поле зрения к уровнюутечка?
2. Является ли реализация тега приложения хорошей практикой (или она должна выполнять проверку в классе действий, а не в представлении)?
3. Является ли accessDA слишком толстым?
4. Следует лимой новый модуль соответствует существующей структуре?

Answer 1

1) ИМО да, но: это не дырявая абстракция как таковая, именно потому, что она в теге. Существуют теги, чтобы абстрагировать детали реализации от представления. Также можно утверждать, что поиск доступа в действии делает действие ответственным за то, что относится только к слою представления.

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

2) Подобный тег должен действовать против текущего объекта пользователя, который должен был уже инкапсулировать права пользователя (возможно, при входе в систему). Тем не менее, может быть недостаточно использовать кэшированные значения для определения прав доступа, если эти права могут измениться во время сеанса пользователя.

3) Не знаю; не зная более подробной информации IMO, на которую невозможно ответить.

4) Зависит. Выполнение одного и того же действия несколькими способами может привести к кошмарам обслуживания.

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

Answer 2

В типичном использовании MVC должно быть четкое Разделение проблем .Значение, модель, вид и часть контроллера должны быть отделены.Позвольте мне ответить на ваши вопросы

1.вызов DAO, это приведет к утечке уровня

Да.В идеале и вызовы DAO должны быть в классе действия / обработчика.Полученные таким образом данные помещаются в запрос / сеанс для последующего получения на уровне рендеринга представления.

2. реализация тега приложения, это хорошая практика? (Или она должна выполнять проверку при действииcla ss вместо вида.)

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

3. Является ли accessDA слишком толстым?

Да.Это выглядит так.

4. Должен ли мой новый модуль следовать существующей структуре?

Сделав вышеизложенные замечания, я бы посоветовал против этого.