Уровень обслуживания приложений - как писать интерфейсы методов API - PullRequest
Новая
       16

Уровень обслуживания приложений - как писать интерфейсы методов API

7 голосов
/ 04 ноября 2010

Как люди проектируют свои интерфейсы уровня обслуживания?

Я программирую большое веб-приложение (на PHP), и мы используем MVC, и программирую тонкие контроллеры, например (псевдокод следует) 

public savePersonAction() {
    $input = filter($_GET);
    ... input validation ...

    $result = $this->_service->savePerson( ? );

    ... etc
}

Должен ли savePerson в службе принимать аргумент всей структуры или контекста $ input (в PHP - ассоциативный массив)?

например. это - 

public function savePerson(array $input) {

или следует отделить все поля ввода и предоставить «жесткий» интерфейс, например 

public function savePerson($title, $firstName, $lastName, $dateOfBirth, ... etc.. for many more) {

Спасибо.

Пол

Ответы [ 3 ]

5 голосов
/ 04 ноября 2010

Если вы собираетесь следовать духу MVC, ваш метод savePerson не должен принимать необработанный ввод.Это не должно быть напрямую связано с форматом данных, поступающих от пользовательского интерфейса.Вместо этого он должен принимать входные данные, определенные в терминах вашего домена обслуживания, как объект «персона».(Это может быть просто ассоциативный массив, как предложил Кобби).Задачей метода действия контроллера будет сопоставление необработанного ввода с форматом, необходимым для службы.

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

Хотя ваш пример типа savePerson($title, $firstName, $lastName...) - правильная идея, обычно это плохой знак, когда у вас есть методы с более чем 2 или 3 аргументами.Вы должны иметь возможность группировать связанные аргументы в какой-то объект более высокого уровня.

1 голос
/ 04 ноября 2010

Мои MVC-приложения имеют следующую структуру: Контроллер -> Сервис -> ORM / другая библиотека

Чтобы ответить на ваш вопрос, обычно в вашем контроллере вы будете получать данные формы в виде массива, то есть $ form-> getValues ​​() или чего-то подобного. С точки зрения удобства обслуживания лучше, если ваши службы, за исключением массивов в качестве аргументов, таким образом, если вы добавляете в форму другое поле, вам нужно только обновить форму и службу, ваш контроллер может остаться нетронутым и по-прежнему работать.

Так что я думаю, что пойти с вашим первым примером: 

public function savePerson($personArray);

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

0 голосов
/ 09 апреля 2015

Я бы выделил все поля ввода и предоставил бы "жесткий" интерфейс в Сервисе, например 

public function savePerson($title, $firstName, $lastName, $dateOfBirth) {...}

Это чище, и никаких предположений не требуется.

...