Разработка N-Tier App. В каком направлении? - PullRequest
2 голосов
/ 25 сентября 2008

Предполагается, что вы реализуете пользовательскую историю, которая требует изменений на всех уровнях от UI (или фасада службы) до DB.

В каком направлении вы двигаетесь?

  • От пользовательского интерфейса до бизнес-уровня, от хранилища до БД?
  • От БД до репозитория к бизнес-уровню до пользовательского интерфейса?
  • Это зависит. (На что?)

Ответы [ 4 ]

2 голосов
/ 27 сентября 2008

Лучший ответ, который я видел на этот вопрос, был предоставлен ребятами из Atomic Object и их шаблоном Presenter First . По сути, это реализация шаблона MVP, в которой (как следует из названия) вы начинаете работать с Presenter.

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

Мне обычно нравится работать таким образом, даже если я не выполняю строгий шаблон MVP. Я считаю, что сосредоточение внимания на взаимодействии с пользователем помогает мне создавать бизнес-объекты, с которыми легче взаимодействовать. Мы также используем Fitnesse у себя дома для интеграционного тестирования, и я считаю, что написание приспособлений для Fitnesse при построении моих бизнес-объектов помогает сосредоточить внимание на взгляде пользователя на историю.

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

1 голос
/ 25 сентября 2008

Если возможны изменения, начните с фронта. Вы можете получить немедленную обратную связь от акционеров. Кто знает? Может быть, они на самом деле не знают, чего хотят. Наблюдайте, как они используют интерфейс (пользовательский интерфейс, сервис или иное). Их действия могут вдохновить вас посмотреть на проблему в новом свете. Если вы можете отловить изменения до кодирования объектов домена и базы данных, вы сэкономите массу времени.

Если требования жесткие, это не так важно. Начните со слоя, который, вероятно, будет самым трудным - обращайтесь к риску рано. В конечном счете, это одна из проблем "больше искусства, чем науки". Вероятно, это тонкое взаимодействие между дизайном слоя, которое создает лучшее решение.

Приветствие.

0 голосов
/ 25 сентября 2008

Я бы начал моделировать проблемную область. Создайте соответствующие классы, представляющие объекты системы. Как только я почувствую уверенность в этом, я попытаюсь найти реальное сопоставление для сохранения сущностей в базе данных. Если вы вкладываете слишком много работы в пользовательский интерфейс до того, как создадите модель домена, существует значительный риск того, что вам потребуется впоследствии переработать пользовательский интерфейс.

Подумав об этом, вам, вероятно, все равно нужно обновить некоторые слои ... =)

0 голосов
/ 25 сентября 2008

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

Хотя есть и другие мнения.

...