Как получить доступ к свойствам класса EF из сервисного уровня - PullRequest
Новая
       40

Как получить доступ к свойствам класса EF из сервисного уровня

0 голосов
/ 20 февраля 2012

У меня есть ASP.NET MVC3 в C # и Razor. Архитектура приложения разделена на уровень доступа к данным (классы EF + репозиторий), уровень обслуживания, контроллер, ViewModels и View.

Из моего сервисного уровня ProductServices я вызываю метод GetAllProducts, предоставляемый моим репозиторием ProductRepository, который имеет следующую подпись: 

IQueryable<Products> GetAllProducts()

Поэтому в ProductServices я звоню (productRepository это экземпляр ProductRepository): 

var products = productRepository.GetAllProducts();

, который заполняет переменную products. Теперь я хотел бы получить доступ к названию продукта ProductName из productServices. Если я использую эту инструкцию: 

var productNames = products.Select(m => m.ProductName).ToList();

Я создаю связь между ServiceLayer и EF (в обход хранилища). Это означает, что я должен добавить к ProductRepository метод с подписью: 

IQueryable<string> GetAllProductsName()

Однако, поскольку в моем приложении нужна другая информация о продукте, я должен создать один метод в productRepository для каждого поля класса Product? Правильно ли мои рассуждения? Спасибо

Ответы [ 2 ]

1 голос
/ 20 февраля 2012

Есть две школы мысли вокруг этого,

  1. Репозиторий явно определяет способ взаимодействия с базой данных и должен строго контролироваться. Поэтому методы в хранилище должны предоставлять перечисляемые данные
  2. Хранилище нарушает сильную связь с конкретным типом источника данных, но не нуждается в предоставлении подробных и перечисляемых наборов данных.

Лично я подписываюсь на второе, вот почему:

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

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

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

Если вам интересно, вот мой взгляд на репозитории: http://blog.staticvoid.co.nz/2011/10/staticvoid-repository-pattern-nuget.html, весь код также на github

0 голосов
/ 20 февраля 2012

У вас есть вся информация в ваших productServices, потому что вы загружаете всю информацию из вашего репозитория с помощью метода productRepository.GetAllProducts ().Если вам нужна дополнительная информация от другой организации, вам необходимо расширить ваши productServices новой службой.

Однако, поскольку мне нужна другая информация о продукте в моем приложении, я должен создать один метод в productRepository длякаждое поле класса Product?Правильно ли мои рассуждения?Спасибо

В этой ситуации обычно я создаю метод Расширения для службы, а не в хранилище.Репозиторий обычно имеет настройку CRUD и ничего более.

...