Когда функциональность должна быть доступна в его собственном контроллере?

Question

Я работаю над веб-приложением, которое должно представлять графики на разных страницах.Каждая страница соответствует Контроллеру, и каждый Контроллер, которому нужна диаграмма, имеет интерфейс с ChartService.Служба запрашивает диаграмму у стороннего поставщика.Затем он возвращает изображение, завернутое в некоторый HTML-код с JavaScript, в виде строки непосредственно в выходной поток.ChartService должен быть снабжен данными и некоторыми другими параметрами, такими как период времени и файл шаблона.

Должен ли я использовать функции построения диаграмм в своем собственном контроллере?Каждый другой тип диаграммы может обслуживаться различным методом действия в ChartController.

Но будет ли тогда проблемой то, что я обслуживаю некоторые из своих страниц с нескольких контроллеров?Каковы рекомендации, чтобы определить, когда функциональности должен быть предоставлен собственный контроллер?

Answer 1

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

Создайте новый контроллер, если вы хотите добавить поведение в приложение.

Answer 2

IMO, если у вас есть секция "построения графиков" с URL-адресами, такими как

charts/income
charts/expenditure

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

products/list
products/yearlyStockChart
employees/details
employees/performanceChart

, тогда вам понадобится контроллер ProductsController с действиями List () и yearStockChart () и контроллер employeeC с действиями details () и performanceChart ()оба контроллера используют услугу построения графиков.

Answer 3

Дейв,

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

[править] - прелесть этого подхода в том, что, если вам повезет, 75% функциональности базового контроллера останутся, и только 25% функций будут переопределены и / или сделана на заказ для этого дочернего контроллера.это дало бы вам очень чистую парадигму, поскольку у каждого нового типа диаграммы была бы своя собственная модель / контроллер с потенциально идентичными именами методов действия, что делало бы стоимость «ввода» для новых типов диаграмм очень дешевой.

jim