#asp.net #asp.net-mvc-3 #asynchronous #subclass #oop
#asp.net #asp.net-mvc-3 #асинхронный #подкласс #ооп
Вопрос:
У меня есть базовый контроллер, который является подклассом стандартного контроллера mvc. Он содержит множество полезных методов, специфичных для контроллера.
Теперь мне нужно иметь некоторую функциональность asych в одном из моих новых контроллеров
Однако для этого вам необходимо создать контроллер, который относится к подклассу AsyncController
Но я также хочу получить доступ к функциональности в моем базовом контроллере
Очевидно, что множественное наследование невозможно
итак, как мне обойти это?
Ответ №1:
Вы могли бы экстернализировать функциональность, которую вы хотите повторно использовать, в уровень сервиса, фильтр действий, фильтр авторизации, связующее модель, … это будет зависеть от функциональности, которую вы хотите повторно использовать, чтобы вы могли легко переключить базовый контроллер на асинхронный контроллер и при этом сохранить функциональность. Если вы хотите использовать асинхронные контроллеры, вам нужно будет получить производные от AsyncController.
Комментарии:
1. допустим, ради аргументации я хочу, чтобы вся функциональность, доступная в моем базовом контроллере, и чтобы база казалась подходящим местом для существования этой функциональности. Кажется странным решение заставить вас создать подкласс для определенного контроллера, чтобы сделать его таким же. это приводит к хрупким / повторяющимся иерархиям наследования — если только я чего-то не упускаю. (Что, конечно, не является чем-то неслыханным)
2. @josedelascasa, нет, ты ничего не упускаешь. Именно так разработчики фреймворка решили это реализовать. Есть некоторые критики против того факта, что они используют абстрактные классы вместо интерфейсов, но так оно и есть, и мы ничего не можем с этим поделать.
Ответ №2:
Вы могли бы заставить свой класс контроллера наследовать IAsyncManagerContainer и IAsyncController , а затем реализовать эту функциональность самостоятельно, возможно, используя код из исходного кода MVC. Вы могли бы даже инкапсулировать это в свой собственный класс, которому вы делегируете функциональность.
Комментарии:
1. да, это неплохая идея. Я думал об этом наоборот — внедряя Icontroller вручную. но было бы меньше работы, чтобы сделать это по-своему. спасибо — пока оставлю этот вопрос открытым для других предложений
2. но все равно придется повторять это для каждого контроллера, которому требуется функциональность asynch, хотя
3. @josedelascasa — Вот почему я предложил инкапсулировать код в его собственный класс, а затем делегировать вызовы. Вы должны реализовать методы для каждого контроллера вручную, но это всего лишь вопрос некоторого шаблонного кода. Вы могли бы даже использовать фрагменты кода для автоматизации этого.
4. ах да, понял. интересно услышать другие подходы. имхо, это довольно плохой недостаток дизайна (то есть наследование)
5. @josedelascasa — Вы также могли бы создать базовый класс, наследуемый от вашего базового класса, который реализует асинхронные интерфейсы. Отсутствие множественного наследования обычно считается особенностью, потому что MI очень сложно выполнить правильно и добавляет системе огромную сложность. Обычно достаточно множественного наследования интерфейса.