Предполагая, что вы реализуете пользовательскую историю, которая требует изменений во всех слоях от пользовательского интерфейса (или служебного фасада) до БД.Разработка приложения N-Tier. В каком направлении?
В каком направлении вы двигаетесь?
Лучший ответ, который я видел на этот вопрос, предоставил ребята Atomic Object и их шаблон Presenter First. В основном это реализация шаблона MVP, в котором (как следует из названия) вы начинаете работать с Presenter.
Это дает вам очень легкий объект (поскольку ведущий в основном предназначен для маршалирования данных от модели к представлению и событий из представления в модель), которые могут непосредственно моделировать ваш набор действий пользователя. При работе с презентатором представление и модель обычно определяются как интерфейсы и издеваются, поэтому ваш основной упор делается на определении того, как пользователь взаимодействует с вашими объектами.
Обычно мне нравится работать таким образом, даже если я не строгу шаблон MVP. Я считаю, что сосредоточение внимания на взаимодействии с пользователем помогает мне создавать бизнес-объекты, с которыми легче взаимодействовать. Мы также используем Fitnesse в доме для тестирования интеграции, и я нахожу, что написание светильников для Fitnesse при построении моих бизнес-объектов помогает сосредоточить внимание на взгляде пользователя на историю.
Я должен сказать, однако, что вы заканчиваете довольно интересный цикл TDD, когда начинаете с неудачного теста Fitnesse, затем создаете неудачный модульный тест для этой функции и прокладываете себе путь к стопке.В некоторых случаях я также пишу тесты модулей базы данных, поэтому есть еще один уровень тестов, которые могут быть написаны, не пройдены и пройдены, до прохождения тестов Fitnesse.
Я бы сделал это снизу вверх, так как у вас будут быстрые рабочие результаты (т.е. вы можете писать модульные тесты без пользовательского интерфейса, но не можете протестировать пользовательский интерфейс до тех пор, пока модель делается).
Есть и другие мнения.
Я бы начал моделировать проблемную область. Создайте соответствующие классы, представляющие объекты системы. Как только я буду уверен в этом, я попытаюсь найти возможное сопоставление для сохранения сущностей в базе данных. Если вы добавили слишком много работы в пользовательский интерфейс, прежде чем у вас появится модель домена, существует значительный риск, что вам необходимо будет повторно использовать интерфейс пользователя.
Думая об этом, вы, вероятно, нужно сделать некоторые обновления, чтобы все слои так или иначе ... =)
Если изменение, вероятно, начнется в передней. Вы можете получить немедленную обратную связь от акционеров. Кто знает? Возможно, они действительно не знают, чего хотят. Наблюдайте за тем, что они используют интерфейс (пользовательский интерфейс, сервис или другое). Их действия могут побудить вас рассмотреть проблему в новом свете. Если вы можете уловить изменения до кодирования объектов домена и базы данных, вы сохраняете массу времени.
Если требования жесткие, это не так важно. Начните в слое, который, вероятно, будет самым сложным - ранний риск. В конечном счете, это одна из проблем «больше искусства, чем науки». Вероятно, это тонкое взаимодействие между дизайном слоя, которое создает лучшее решение.
Cheers.