ASP.NET MVC - Linq к модели Entities как ViewModel - является этой хорошей практикой? [закрытый]
Если Вы смотрите в базе данных временных файлов, Вы видите временные таблицы там, и у них есть имена, генерируемые системой. Таким образом кроме регулярных мертвых блокировок необходимо быть в порядке.
2 ответа
Я бы посоветовал просмотреть код отрисовки в ваших представлениях и код публикации в ваших контроллерах. Не слишком ли сложны они из-за вашего подхода? Если нет, вы, вероятно, можете оставить все как есть. Если представление и код контроллера можно было бы значительно упростить за счет введения пользовательской модели представления, подумайте о ее создании. Пользовательские модели представления по существу абстрагируют часть этой сложности, которая, вероятно, сейчас решается где-то еще.
Если ваши представления начинают делать что-то вроде
<% foreach (var order в Model.Orders.Any (x => x.Products.Any (p => p.Category ==) "xx"))%>
, тогда вам определенно понадобится ViewModel. Вы можете использовать
ViewData ["flattened_orders"]
, если предпочитаете магические строки, но я сомневаюсь в этом.
Тогда есть вопрос об атрибутах представления, необходимых для ваших сущностей, тогда вам нужно раскрыть все свойства на них, чтобы связка модели могла работать ... тогда вам нужна дополнительная информация только для презентации, такая как список стран ...
Итак, для простых приложений , вы можете пропустить ViewModel, но для простых приложений вы все равно можете использовать Response.Write и ручной SQL; -)
Мне действительно нравится этот пост о подобной проблеме. Представленный там подход может показаться слишком "академическим".