Есть ли смысл иметь несколько проектов VS для приложения ASP.NET MVC? - PullRequest
Новая
       6

Есть ли смысл иметь несколько проектов VS для приложения ASP.NET MVC?

1 голос
/ 18 марта 2010

Я занимаюсь разработкой приложения MVC, в котором в данный момент у меня есть 3 проекта.

  • Core (это должно быть для репозиториев, бизнес-классов, моделей, HttpModules, HttpFilters, настроек и т. Д.)
  • Доступ к данным (поставщик данных, например SqlDataProvider для работы с хранилищем данных SQL Server - реализует интерфейсы репозитория, XmlDataProvider - также реализует интерфейсы репозитория, но для локальных файлов XML в качестве хранилища данных)
  • Проект ASP.NET MVC (все типичные вещи, пользовательский интерфейс, контроллеры, контент, скрипты, ресурсы и помощники).

У меня нет моделей в моем проекте ASP.NET MVC. Я только что столкнулся с проблемой из-за этого, потому что я хочу использовать новую функцию DataAnnotation в MVC 2 в своем бизнес-классе, которая как и в Core , однако я хочу иметь возможность локализовать сообщения об ошибках. Это где моя проблема начинается. Я не могу использовать свои ресурсы из проекта MVC в Core . Проект MVC ссылается на Core, и наоборот не может быть.

Мои варианты, как я их вижу: 1) Удалите ресурсы, но для этого потребуется исправить целую кучу представлений и контроллеров, где я на них ссылаюсь, 2) Сделать полную реструктуризацию моего приложения

Что вы думаете об этом? Кроме того, я должен просто переместить все, что связано с бизнесом, в папку Models в проекте MVC ?? Имеет ли смысл иметь такую ​​структуру, потому что мы можем просто создавать подпапки для всего в рамках проекта MVC? Вся библиотека Core не предназначена для чего-либо еще, поэтому на самом деле нет смысла компилировать ее в отдельную DLL.

Предложения приветствуются.

1 Ответ

2 голосов
/ 18 марта 2010

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

Некоторые люди говорят, что это усложняет "замену реализации", которая является глупостью. Поменять содержимое папки так же просто, как поменять проект.

Источник MVC - это то, что заставило меня полюбить этот подход. Они все выровняли, и их исходный код действительно легко плавать.

...