ASP.NET MVC - модельные интерфейсы

Question

Похоже, что теперь я решил все свои проблемы LINQ, я не работаю над созданием реальной модели. Дело в том, что я не хочу быть привязанным к одной технологии, я хочу иметь свободу для реализации различных технологий доступа к данным и работы с одним интерфейсом.

Теперь я никогда не делал этого раньше, но, основываясь на своих знаниях и опыте ООП, я придумал такую ​​идею:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Data.Linq;

namespace Intranet.Data.Accounts
{
  interface IContractsControl
  {
    ContractsControlViewData GetContracts(System.Nullable<int> contractTypeID,
                                  System.Nullable<int> responsibilityID,
                                  string expenseType,
                                  System.Nullable<int> supplierID,
                                  string businessID);

    ContractsControlViewData GetContract(int contractID);
  }
}

У меня есть несколько вопросов о том, как это должно работать.

1. Где должен жить интерфейс, учитывая, что я использую библиотеку областей, разработанную Филом Хааком. На данный момент я создал папку с именем «Данные» на корневом уровне (как вы можете видеть из пространства имен).
2. Наши хранимые процедуры имеют ложные имена, потому что они объединяются в базу данных, если я использую объекты, я вместо этого могу работать над объектно-ориентированным решением для доступа к sprocs. Должны ли имена в моей библиотеке доступа к данным отражать имена хранимых процедур в этом случае?
3. Использование такой библиотеки позволило бы мне сделать Accounts.GetContracts() в моем контроллере. Это мудро?
4. Есть ли какие-либо рекомендации по проектированию для этого подхода? схемы именования.
5. Где должна существовать фактическая реализация? В той же папке, что и интерфейс?

Идея состоит в том, что если мы когда-нибудь откажемся от LINQ, то вместо этого мы можем использовать другую технологию доступа к данным (инфраструктура сущностей, обычный SQL и т. Д.). Я хотел бы услышать комментарии / критические замечания / оценки от более опытных.

Answer 1

Ваш подход очень похож на шаблон репозитория, высоко оцениваемый многими авторами учебников по ASP.NET MVC ... =) Вот учебник , который описывает, как сделать существующее приложение слабо связанным, и одну вещь ( среди прочего) показывает, как реализовать шаблон репозитория в ASP.NET MVC.

Answer 2

IMultipleResults для меня торчит, как больной большой палец. Он точно не объявляет реальный тип возврата вызывающей стороне.

Если вы хотите истинную абстракцию репозитория, вы можете иметь отдельный тип Contract, который не имеет ничего общего с вашим инструментом ORM, и возвращать их массив / список. Некоторые фреймворки (NHibernate, LINQ-to-SQL, если вы работаете достаточно усердно, EF в 4.0) поддерживают использование POCO, что позволяет вам использовать ваши простые (не ORM) объекты с помощью инструмента ORM. Так что мои предпочтения будут:

• репозиторий на основе интерфейса, возвращающий массивы / списки / и т.д. из ...
• ... конкретные типы POCO

Дополнительная абстракция типа данных интерфейса разрушает некоторые установки привязки данных (например, он не может создавать новые записи).