Использование Entity Framework для возврата таблицы данных для итерации - PullRequest
Новая
       47

Использование Entity Framework для возврата таблицы данных для итерации

0 голосов
/ 07 декабря 2018

В настоящее время я использую EF 6 для следующих действий.Выполните хранимую процедуру, затем введите данные, которые мне нужны.Данные обычно содержат 30-40 строк на один запуск приложения.

Затем я перебираю переменную var, object, table (как бы вы это ни называли), выполняя аналогичные (иногда разные) задачи для каждой строки.Работает отлично.Я могу создать объект Entity, выставить различные его сложные функции, а затем создать переменную для итерации.

Как: 

foreach (var result in StoredProcedureResult)
{
string strFirstname = result.FirstName
string strLastName = result.LastName
//more logic goes here using those variables and interacting with another app

}

Недавно я подумал, что это будет крутоесли бы у меня был класс исключительно для доступа к данным.Таким образом, я мог бы просто сослаться на этот класс, добавить соответствующую строку подключения в мой app.config, и тогда я смогу разделить два набора логики.Таким образом, пытаясь выполнить вышеупомянутое в этой структуре, я дохожу до того, что вы не можете вернуть переменную, или когда я пытаюсь сопоставить тип возвращаемого объекта.Возвращаемым типом выполнения хранимой процедуры является объект (который я не могу повторить).

Итак, мой вопрос: как можно получить приведенный выше пример, кроме результата var, возвращаемого из этого класса доступа к данным?

Если я что-то упустил или это невозможнопотому что я делаю это неправильно, дайте мне знать.Это появилось прямо в моей голове.

1 Ответ

0 голосов
/ 11 декабря 2018

Я не собираюсь описывать архитектуру полностью.Но на основе ваших комментариев вы можете сделать следующее (это не единственный и не единственный способ сделать это):

  1. в вашем проекте доступа к данным вы сохраняете класс DBContext, весь код длявызов хранимой процедуры, а также класс, который определяет результат вызова SP, давайте назовем его классом A;
  2. в вашем проекте общего уровня - я бы предложил назвать его Service layer - вы можете создать класс XYService,у которого есть метод, например GetListOfX, который подключается к БД и вызывает процедуру, при необходимости этот метод также может выполнять некоторую логику, но что более важно: он не возвращает класс A, но возвращает новый класс B (этотопределено на уровне сервиса или может быть определено в другом проекте - это может быть настоящий общий / общий проект, так как это будет просто определение общих структур, на самом деле это не слой);
  3. на вашем прикладном уровне вы работаете только с методом GetListOfX XYService и с классом B, поэтому вам не нужна ссылка напроект доступа к данным

В тривиальном случае класс B имеет те же свойства, что и класс A. Но, в зависимости от ваших потребностей, класс B может иметь дополнительные свойства / функциональность, он также может игнорировать некоторые свойства Aили даже объединить несколько свойств в одно: например, объединить FirstName и LastName в одно свойство, называемое просто Name.

По сути, вы ищете многоуровневую архитектуру приложения (обычно 3-4 уровня).Полный объем такого подхода (который включает в себя интенсивное использование таких понятий, как интерфейсы и внедрение зависимостей) может оказаться неподходящим или необходимым в зависимости от ваших целей, например, если вы создаете для себя небольшое приложение с парой функций или знаете, что тамне будет повторного использования компонентов окончательного решения, тогда этот подход слишком расточителен, и вы сможете быстрее работать со всем в одном проекте - вы все равно должны применять такие принципы, как SOLID , DRY и Разделение интересов .

...