Вы должны быть готовы обратить внимание на несколько улучшений.
• Схема взаимодействия классов (изображенная на рис. 25.3) намного более проста и удобна для чтения, что указывает на усовершенствование, к которому приводит расцепление классов.
• Расцепляя интерфейс модели от основной структуры базы данных, мы уменьшаем и упрощаем код контроллера. Если для вашего офиса требуются новые компьютеры то заказать Сборку компьютеров на заказ можете тут.
• Каждый класс модели создает объекты, чтобы взаимодействовать с одной или более таблицами. Контроллерам нет необходимости знать, какие таблицы участвуют в этом взаимодействии.
• Классы моделей инкапсулируют и скрывают запросы к базе данных. Контроллер заинтересован только в поиске пользовательских вводов и выводов задач более высокого уровня через API-интерфейс модели.
• В некоторых случаях запрос может быть слишком сложным, чтобы легко пройти через взаимодействие с DAO-объектом, в связи с чем требуется написание пользовательского SQL-кода.
Тестирование простых объектов
В идеале нужно суметь протестировать модель, не подключаясь к оперативной базе данных. Если вы расцепляете модель от ее DAO-объекта, то вы можете создать заглушки и фиктивные DAO-объекты, чтобы содействовать поблочному тестированию вашей модели.
Аналогично вы можете тестировать интерфейс модели домена точно так же, как в любом другом объектноориентированном тестировании: вызовите метод объекта, а затем проверьте корректность возвращаемого методом значения. Это быстрее и проще, чем создание ложных HTTP-запросов, полагаясь на контроллер и парсинг результирующего ответа HTTP-протокола.
Вы по-прежнему тестируете контроллеры ложными HTTP-запросами, но поскольку код контроллера стал проще, больше нет необходимости в тестировании большого количества логических путей.
Главная
Каталог файлов
