Я вставлял свои классы viewdata внутри своих контроллеров, и по мере роста их числа я начинаю спрашивать себя, является ли это хорошей идеей. Опять же, что-то о загрязнении каталогов/Views и/Controllers с этими вещами кажется неактивным.Где я должен помещать свои данные с жесткими именами asp.net-mvc?
Есть ли соглашение, которое я здесь отсутствует? Может быть, каталог/ViewData? idk, какие хорошие места для моих классов viewdata?
Я сделал именно то, что вы предлагаете, у меня есть очень сильно напечатанные viewdata, живущие в/ViewData. Я думал о том, чтобы поместить его в каталог \ Model, но мне не нравятся мои проекты с слишком большим количеством вложенных каталогов. \ ViewData - это то, что делает Kigg.
Я поместил свои классы данных представления в проект, посвященный именно этому. Это DTO, и включение их в собственный проект предусматривает, что они не зависят от чего-либо выше в архитектурных слоях.
Использование их как DTO для доставки к просмотру - это лишь один из способов их использования. Я могу отправить их через провод некоторое время, внутри сообщения на служебной шине или что-то еще.
Я не знаю конвенции. Я просто положил шахту под /Model/ViewModel/BlahViewModel.cs и т. Д. Я бы не поместил их в отдельный проект, пока не возникла определенная потребность в этом. В случае необходимости им было бы нелегко переместить их позже.
, так как вы используете MVC и структуру папок должны отражать структуру пространства имен вашего кода я бы рекомендовал для каждого из объектов доменов вы должны группировать контроллеры, модели и услуги на отдельные папки
мы будем использовать
DomainName
Controllers
Model
Services
правильно, но где вы бы поместили классы viewdata? Контроллеры и представления зависят от них. –
В папке модели, так как вы захотите передать модель на представление с контроллера. MvcContrib имеет несколько превосходных расширений, позволяющих передавать модели данных в такие данные, как ViewData.Add (modelInstance) и ViewData.Get() –
Richard