Общие представления модели в ASP.NET MVC

Question

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

This tutorial переводит выделение для высокого повторного использования, но что происходит, если представление данных между объектами и LINQ изменяется настолько незначительно? Тогда вам придется изменить представление. Являются ли классы, созданные LINQ и сущностями, гарантированно одинаковыми, когда они передаются в представление? Можно ли создать класс/интерфейс, который в общем случае представляет данные?

Пример

namespace Intranet.Areas.Accounts.ViewModels 
{ 
    using Intranet.Areas.Accounts; 
    using System.Collections.Generic; 
    using Intranet.Areas.Accounts.Models; 

    public class ContractsControlViewData 
    { 
    public IEnumerable<Contract> Contracts { get; set; } 
    public IEnumerable<tblCC_Contract_CC> tblCC_Contract_CCs { get; set; } 
    public IEnumerable<tblCC_Contract_Data_Terminal> tblCC_Contract_Data_Terminals { get; set; } 
    public IEnumerable<tblCC_CDT_Data_Service> tblCC_CDT_Data_Services { get; set; } 
    public IEnumerable<tblCC_Data_Service> tblCC_Data_Services { get; set; } 
    } 
} 

Приведенный выше код взят из небольшого проекта я тестирование. Обратите внимание, что у меня есть типы, начинающиеся с «tbl». Я просто перетащил их из базы данных в конструктор LINQ, и я использую их в этом контейнере, который передается в представление, чтобы впоследствии отображать несколько наборов результатов на экране.

Проблема заключается в том, что если я откажу LINQ и использую объекты, будут ли данные по-прежнему отражаться так же, как представленные здесь типы? Будет ли еще Contract? Имейте в виду, что эти типы в предыдущем примере кода генерируются LINQ. Насколько они совместимы, если вы используете другую технологию доступа к данным?

Вот почему я задаюсь вопросом, должны ли мы для разделения проблем и для согласованности данных создавать собственные классы для последовательного представления данных.

Мой мозг болит, кто-то спасает меня от себя.

Answer 1

Не будет ли класс, который вы создаете, быть очень близким к DataTable, DataRow или даже NameValueCollection? Ваш объект должен был бы включать его схему как часть себя, и View должен был бы перебирать коллекцию (ы).

Answer 2

Вот почему я задаюсь вопросом, должны ли мы для разделения проблем и обеспечения согласованности данных создавать собственные классы для последовательного представления данных.

Да 100%

У меня нет опыта работы с LINQ к SQL и лиц себя. Я использовал другую ORM, и первое, что я всегда проверял, было, если я все еще могу использовать свои собственные классы POCO во всех слоях.

В моем офисе некоторые коллеги создали довольно большое приложение, использующее linq для sql. Мне было трудно поверить, что это возможно, из-за того, как изменения в БД будут пульсировать по всем слоям.

У них даже есть смешная проблема со времен SP1 на немецком языке: все классы коллекций получили некоторый немецкий индикатор для множественности. Это довольно здорово, если у вас есть разработчики в нескольких странах. Лучше не позволяйте разработчикам в Китае восстанавливать ваш dbml.

Оказалось, что мои коллеги сделали именно то, что вы описали: у них были свои собственные модели (Poco), которые они сопоставляют с созданными классами linq в слое DB.