Слой DataAccess для возврата объектов домена в случае Ado.net? - PullRequest
0 голосов
/ 12 декабря 2018

Я создаю проект, в котором я буду использовать ADO.NET в качестве слоя доступа к данным для взаимодействия с базой данных.

Теперь вещь, в которой я сильно запутался, связана с:

1) Должен ли я иметь доменные объекты в этом приложении?

2) Всегда ли мой результат запроса sql должен быть связан с доменными объектами ?

3) Если я не использую доменобъекты, тогда я всегда буду возвращать пользовательские модели из уровня доступа к данным, которые имеют все, что я хочу вернуть в моем веб-API-сервисе?

4) Если я использую модели домена и если есть сценарий, в котором я хочу отобразить данные из нескольких таблиц или сценарий, например, такой как:

public class Employee
   {
      int id;
      List<Skills>();
   }

Я могу легко сделать это в EF, но с ado.net и с объектом домена, который будету меня есть такая структура, как показано ниже:

public class Employee
   {
       int id;
   }

   public class Skill
   {
       int id;
       int EmployeeId;
   }

Конечно, я могу сначала получить список сотрудников, а затем для каждого сотрудника я могу получить список навыков на основе идентификатора сотрудника, но разве это не будет болезненноti придется запускать запрос для каждого сотрудника, чтобы получить соответствующие навыки, что довольно просто в EF на основе свойства навигации и позволяет избежать накладных расходов, как показано ниже:

var employees = //get listof employee in this case domain model 
                  List<Employee>
var employeeModel = new List<EmployeeModel>();
foreach(var employee in employees)
{
   EmployeeModel model = new EmployeeModel();
   model.id = employee.id;
   var skills = GetSkill(employee.id);//Get list of skills in this case 
                domain model List<Skill>;
   employeeModel.Skills =  new List<SkillModel>();
   foreach(var skill in skills)
   {
      SkillModel sm = new SkillModel();
      sm.Id = skill.Id;
      employeeModel.Skills.Add(smm);
   }
   employeeModel.Add(model);
}

Наконец, эта модель EmployeeModel будет возвращена в качестве ответа в моемСервис Web Api, следовательно, этот EmployeeModel будет содержать только те свойства, которые я верну в моей конечной точке WebApi.

Какой должна быть архитектура, рассматриваемая при работе с ado.net в качестве слоя доступа к данным, и я буду очень признателенесли кто-то может помочь мне решить вышеуказанные проблемы.

Примечание: Я не хочу использовать ORM (Entity Framework или Dapper и т. д.).

Ответы [ 6 ]

0 голосов
/ 20 января 2019

Я просто хотел предоставить вам другую альтернативу для сценария 4.

4) Если я использую модели домена и если существует сценарий, в котором я хочу отображать данные из> нескольких таблиц или сценариявот так

Посмотрите на ответ, который я дал на следующий вопрос: Загрузка связанных объектов в память (без ORM)

Я используюанонимные типы и LINQ для сопоставления данных для запроса по нескольким таблицам.

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

Я согласен с Тенгизом ответом.Тем не менее, вы можете использовать шаблон Active Record , и если вы подразумеваете, что под доменным объектом вы хотели бы использовать подход проектирования на основе домена, тогда ваш DAL должен абстрагировать логику доступа к данным внутри, и вам лучше использовать Repositoryшаблон для каждого объекта агрегирования домена.Кроме того, вы можете разделить ваши модели для чтения и записи, затем вы можете использовать шаблон CQRS .

В любом случае вам нужно запустить свои команды / хранимые процедуры sql в ваших объектах доступа к данным, а затемзаполнить ваши доменные объекты из ADO.NET, наборы данных, datatable и представить их для вашей доменной модели.

В качестве примечания, DTO в его названии используется для связи с вашим внутренним доменом, и этоРекомендуется отделять ваши доменные объекты от DTO (Контракты на данные).

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

Я постараюсь дать более конкретные ответы, которые должны дать вам практические рекомендации.

1) Должны ли я иметь доменные объекты в этом приложении?

Это зависит.Для очень простых приложений вам это не нужно.Для более сложных приложений это абсолютно рекомендуется.

2) Должен ли результат моего sql-запроса всегда связываться с объектами домена?

Да, если вы собираетесь иметьдоменная модель.Нет, если у вас нет доменной модели или вы пытаетесь вернуть простое значение (например, целое число).

3) Если я не использую доменные объекты, я всегда буду возвращать пользовательские модели изслой доступа к данным, в котором есть все, что я хочу вернуть в своем сервисе веб-API?

Если у вас нет модели домена, тогда ваш DAL станет прямым слугой сервиса веб-API.Итак, все, что нужно веб-API, нужно получить от DAL.Вы можете вернуть все это за один раз (один вызов метода), или вы можете сделать вызов API DAL через несколько вызовов метода.Очевидно, что лучше получить все за один раз, но это лучше вписывается в уровень обслуживания.DAL должен возвращать агрегат за один раз.Но без модели предметной области и более продвинутых подходов об этом можно думать слишком много.

4) Если я использую модели предметной области и если существует сценарий, в котором я хочу отображать данные из нескольких таблиц илиСценарий, подобный этому

Я бы запустил SQL-запрос с объединением.Затем я перебирал строки и создавал родительские и дочерние объекты из строк, а затем возвращал объект таким образом.Фактически, это то, что Entity Framework делает со свойствами навигации - он загружает всю структуру, используя соединение.Он не выполняет несколько запросов, и вы тоже не должны этого делать, если хотите максимально оптимизировать его.

Дайте мне знать, если у вас есть вопросы по поводу всего, что я упомянул.

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

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

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

1) Должны ли я иметь доменные объекты в этом приложении?

только вы можете ответить на это;Правильный ответ сильно зависит от того, что вы делаете с результатами запросов к базе данных.Если в вашем коде C # есть некоторая логика, специфичная для полей, имеет смысл использовать DTO (классы сущностей POCO).Но иногда вам может потребоваться выполнить какой-либо запрос и вернуть результаты в виде JSON, и в этом случае DTO могут быть излишними.

2) Всегда ли мой результат запроса sql должен быть связан с объектами домена?

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

3) Если я неиспользовать объекты домена, тогда я всегда буду возвращать пользовательские модели из слоя доступа к данным, которые имеют все, что я хочу вернуть в моем веб-API-сервисе?

Если вы не используете модели POCO, вы можете составить JSON вваш код и вернуть его как ActionResult.

4) Если я использую доменные модели и есть сценарий, в котором я хочу отображать данные из нескольких таблиц

Если выне используйте ORM как EF 2 возможных случая:

  • , если это результат двух (или более) объединенных таблиц: для этой цели вы можете добавить специальную модель POCO именно для этого результата запроса, илииспользуйте универсальный контейнер данных, например DataTable, для обработки результата
  • , если это родитель-потомок (1-n): выполните 2 запроса и получите результат в виде 2 коллекций модели POCO (скажем, List<Employee> и List<Skills>из гоэти сотрудники).Затем, если вам нужен доступ к дочерним элементам конкретной «родительской» сущности, выполните дополнительную фильтрацию с помощью LINQ.

Если вы не хотите использовать EF или Dapper, вы также можете проверить my library, который может использоваться либо с моделями POCO, либо с общими структурами, такими как DataTable (в дополнение к этому он предлагает структуру RecordSet).

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

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

Создайте представление SQL Server, которое связывает таблицу Employee and Skills и добавьте ее в модель EF.Представление может быть минимальным или максимальным, как вы хотите (например, минимальное, как только для идентификаторов объектов, или максимальное, как во всех полях).

В этом представлении выберите все записи с определенным идентификатором навыка, и теперь у вас естьСотрудники вам требуются.Поскольку представление скомпилировано в SQL Server, оно будет выполнено настолько быстро, насколько вы сможете.

Вы также можете присоединить объекты Employee и Skill в своем коде и вернуть только сотрудников.В LINQ вы можете просмотреть SQL, сгенерированный для вашего кода

...