Типовые представления моделей в ASP.NET MVC

Question

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

В этом руководстве рассматривается разделение для обеспечения высокой возможности повторного использования, но что произойдет, если представление данных между сущностями и 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

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

Да, 100%

У меня нет опыта работы с linq to sql и сущностями. Я использовал другой ORM, и первое, что я всегда проверял, было ли я по-прежнему использовать свои собственные классы POCO во всех слоях.

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

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

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

Answer 2

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