Как мне пространство имен моих моделей в ASP.NET MVC? Смущенный о Ботаническом Обеде

Question

Я изучаю ASP.NET MVC, и мне это нравится. Однако я очень озадачен правильным подходом к пространству имен в моих моделях.

Разбирая образец приложения NerdDinner, я заметил, что все в папке Models принадлежит пространству имен Models. Классы отображения данных, репозитории, управление правилами ошибок и т. Д. Принадлежат к одному и тому же уровню пространства имен.

Я понимаю, что эта папка была вдохновлена ​​фреймворками, такими как Rails и друзья, и что она требуется для оправдания буквы M в названии MVC, но; не разрушает ли автоматическое пространство имен Model какие-либо шансы на написание бизнес-логики, которая может быть отсоединяемой и переносимой в разных системах и реализациях?

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

Существуют ли какие-нибудь сложные и хорошие примеры приложений ASP.NET MVC, которые продемонстрировали бы это?

Answer 1

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

Лично я ничего не помещаю в папку «Модель» и создаю отдельные проекты для своих сущностей (App.Domain) и для доменных служб (App.Services). Я также создаю проекты .Tests для обоих проектов.

Answer 2

Мои разработчики сказали мне, что мы должны полностью реорганизовать наши модели данных в другой проект. Некоторые даже зашли так далеко, что создали ваши бизнес-объекты в еще одном проекте и создали их из классов Linq-Sql.

Я полагал, что Скотт и Ко пошли бы путем, по крайней мере, отделить модель данных от уровня представления. Мы все знаем о преимуществах разделения интересов, но меня удивляет то, как они хранили модель данных в приложении MVC.

Есть еще предложения по более многослойному подходу?