В каком порядке мы должны реализовать приложение Asp.Net Mvc

Question

Это может быть странный вопрос, но я просто собираюсь запустить новое веб-приложение среднего размера, используя Asp.Net MVC.

У каждого человека свой подход к решению, но всегда следуют некоторые практики.

При работе с приложением Asp.Net Forms я всегда работал в следующем порядке

• База данных
• Уровень доступа к данным (сущности LinqToSql / Ado.Net и т. Д.)
• BLL (уровень бизнес-логики + бизнес-объекты)
• Front End (формы, дизайн и т. Д.)
• Аутентификация, Тестирование (интеграция) и др.

(параллельное модульное тестирование начинается с BLL)

Теперь я закончил книги и учебные пособия по MVC и собираюсь начать работу над Приложением. База данных уже есть. Я буду использовать LinqToSql для DAL (модели).

Какой порядок следует соблюдать для реализации Модель , Вид и Контроллер . Я в замешательстве, так как все уроки имеют разный подход.

Как. некоторые начинаются с таблицы маршрутизации, другие начинаются с компонента Controllers, затем касаются Views, а затем советуют перенести логику в модели: «Если Controllerskeep on растет».

Некоторые учат работать с наборами контроллеров -> Вид (ы) -> Модели (и), для каждого процесса в спецификации.

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

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

ПРИМЕЧАНИЕ: будет использовать C #, Sql Server 2005, JQuery, CSS, Visual Studio 2008 и команду из двух человек, бета-версию и ожидается несколько ревизий (компонентов). Спасибо

Answer 1

Это зависит.

1. Начните с базы данных, если она у вас уже есть, и это большая часть приложения.В этом случае используйте Entity Framework, так как он более ориентирован на данные.
2. Начните с пользовательского интерфейса, если у вас есть сложный пользовательский интерфейс и пользователи, которые могут предоставить вам обратную связь.
3. Начните с сущностей, если бизнеслогика - король, а пользовательский интерфейс - гражданин второго сорта.Это поможет с такими вещами, как TDD / DDD.

Я думаю, вы можете объединить 2/3 и интегрировать их в какой-то момент.Если вы основываете одно на другом (пользовательский интерфейс на объектах домена или наоборот), они могут влиять друг на друга, что не очень хорошо.Например, я использовал для разработки своих ViewModels после доменных сущностей, что привело к запутанным моделям представлений / представлений, которые унаследовали множество дизайнов доменных сущностей.

Независимый пользовательский интерфейс поможет в быстрой обратной связи и хорошо проработанных видах и моделях.Самостоятельное создание уровня домена поможет сохранить твердый дизайн ядра.Выполнение обоих независимо предоставит вам 2 точки зрения, которые, подобно стереозрению, дают намного больше деталей по всей картине.Ключевым моментом здесь является связь между доменом и разработчиком (-ями) пользовательского интерфейса и клиентами.

Answer 2

Я склонен начинать с пользовательского интерфейса и работать в обратном направлении. Это сделано для того, чтобы я мог работать с пользователями и бизнес-аналитиками при создании приложения. Я изложил общий процесс в этом посте.

Answer 3

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

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

Это может включать создание новых классов / методов, и они делают это, а также создание интерфейсов и передачу интерфейсов в контроллер (интенсивное использование IOC).

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

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

Это означает, что мы имеем 100% охват сверху вниз, и результат часто является хорошо продуманным решением проблемы.

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

Answer 4

Реальные преимущества ASP.NET MVC в том, что вы можете использовать Test Driven Design для очень чистого построения решений;поэтому я рекомендую начать с испытаний и двигаться назад.

http://weblogs.asp.net/shijuvarghese/archive/2009/07/22/introduction-to-test-driven-development-with-asp-net-mvc.aspx

http://www.wrox.com/WileyCDA/WroxTitle/ASP-NET-MVC-1-0-Test-Driven-Development-Problem-Design-Solution.productCd-0470447621.html

http://elijahmanor.com/webdevdotnet/post/ASPNET-MVC-10-TDD-Book-Review.aspx