Правильный способ использования ORM в ASP.NET Core MVC?

Question

Правильный способ использования ORM в ASP.NET Core MVC?

2

Неопытный веб-разработчик кричит о помощи!

Вступление

Я разрабатываю веб-приложение MVC (используя ASP.NET Core из-за моего интереса к нему). На внутреннем сервере имеется MSSQL-сервер с довольно сложными базами данных (тысячи таблиц). В моем проекте я хотел бы представить часть общедоступных данных в представлении (в таблицах) на основе пользовательских запросов (отправка запросов формы), а затем позволяет пользователю загружать данные (CSV, XML).

Проблемы архитектуры

Уровень доступа к данным

Сначала я начал с использования Entity Framework, но позже понял, что просто не могу перевести все мои операторы SQL в LINQ. Причина в том, что самый простой запрос содержит несколько инструкций INNER JOINS и LEFT JOINS и SELECT и бесконечное количество таблиц.

Уровень бизнес-логики

Я планирую создать REST API, посылая данные в формате JSON. Насколько я заинтересован в.NET Core MVC, я могу иметь свой контроллер API в том же проекте, что и мой уровень представления.

Уровень презентации

Это единственная часть, с которой я сталкиваюсь, создание веб-приложений с использованием MVC 5.

Большая борьба

В этом проекте я не буду манипулировать данными, только ПРОЧИТАЙТЕ его и представить их пользователю. Я знаю принципы использования разных классов модели (Domain, Entity, ViewModel)

Что я делаю сейчас, и я полагаю, что это неправильно:

Контроллер MVC API возвращает результаты запроса SQL как объект типа DataTable (имеет класс SQL Helper для выполнения задания), пока мой контроллер позаботится о сериализации объектов как JSON.
Другой контроллер (с привязкой модели к представлению) получает критерии поиска пользователя через HTML-формы и вызывает контроллер API с привязкой соответствующих свойств.

Наконец, вопросы

Должен ли я придерживаться необработанных SQL-запросов вместо Entity Framework, и если да, то следует ли использовать просто разделенные библиотеки классов (как уровень доступа к данным) и ссылаться на него в API? Или оставить DAL и поместить всю логику SQL-запросов в API?
Нужно ли использовать Entity Framework в случае чтения данных без их манипулирования? Единственная манипуляция, которую я намереваюсь сделать, - форматировать внешний вид в логическом слое.

ОБНОВЛЕНИЕ РЕДАКТИРОВАНИЯ:

В моих SQL-запросах я должен создавать временные таблицы, которые не поддерживаются в LINQ. Какие-либо предложения?

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

Спасибо заранее!

ystvan 10 сен. 2017, в 19:37

Источник

0

«это самый простой запрос, содержащий несколько операторов INNER JOINS и LEFT JOINS и SELECT, а также бесконечное число таблиц»: очевидно, что «endless» - это гипербола, без этого LINQ to Entities будет вполне успешно обрабатывать многофакторные соединения. Но приходит время, когда вам нужно написать SQL, вызвать UDF или SProc: все в EF без потери отслеживания изменений, что делает ORM, подобный EF, выигрышем в производительности.
Richard 10 сен. 2017, в 17:37
0

Спасибо, @Richard Тогда я определенно пойду вокруг LINQ to Entities.
ystvan 10 сен. 2017, в 17:51
1

Если у вас есть сложные сценарии базы данных (включая переменные и временные таблицы), я предлагаю вам создать специальную схему в вашей базе данных, сохранить эти сценарии как представления или хранимые процедуры. Затем вы можете использовать платформу сущностей для доступа к этим объектам. Или вы можете получить к ним доступ напрямую через ваш dbcontext. Для системы только для чтения, которая работает с существующими сложными запросами SQL, я не вижу смысла в преобразовании в LINQ
Nick.McDermaid 12 сен. 2017, в 04:17
0

@Nick.McDermaidNick.McDermaid большое спасибо за ваше полезное руководство! Для новичка EF, как и я, ваш комментарий является чрезвычайно ценным и ставит меня на правильный путь для дальнейшего расследования!
ystvan 12 сен. 2017, в 07:56
0

Я все еще заметил, что ядро EF работает медленнее, чем dapper. Поэтому я выбираю dapper, но каков будет профессиональный способ реализации Asp.net.core + Dapper + PostgreSQL с точки зрения архитектуры.
Rashmin Javiya 03 окт. 2018, в 08:32

Показать ещё 3 комментария

Теги:

sql-server

c#

asp.net-core

entity-framework

multi-tier

1 ответ

Ещё вопросы

«это самый простой запрос, содержащий несколько операторов INNER JOINS и LEFT JOINS и SELECT, а также бесконечное число таблиц»: очевидно, что «endless» - это гипербола, без этого LINQ to Entities будет вполне успешно обрабатывать многофакторные соединения. Но приходит время, когда вам нужно написать SQL, вызвать UDF или SProc: все в EF без потери отслеживания изменений, что делает ORM, подобный EF, выигрышем в производительности.
Спасибо, @Richard Тогда я определенно пойду вокруг LINQ to Entities.
Если у вас есть сложные сценарии базы данных (включая переменные и временные таблицы), я предлагаю вам создать специальную схему в вашей базе данных, сохранить эти сценарии как представления или хранимые процедуры. Затем вы можете использовать платформу сущностей для доступа к этим объектам. Или вы можете получить к ним доступ напрямую через ваш dbcontext. Для системы только для чтения, которая работает с существующими сложными запросами SQL, я не вижу смысла в преобразовании в LINQ
@Nick.McDermaidNick.McDermaid большое спасибо за ваше полезное руководство! Для новичка EF, как и я, ваш комментарий является чрезвычайно ценным и ставит меня на правильный путь для дальнейшего расследования!
Я все еще заметил, что ядро EF работает медленнее, чем dapper. Поэтому я выбираю dapper, но каков будет профессиональный способ реализации Asp.net.core + Dapper + PostgreSQL с точки зрения архитектуры.

howardlo · Accepted Answer · 2017-09-11T23-20-00.000Z

Вы найдете запросы LINQ намного легче понять и отладить, чем SQL. Сохраняйте уровень доступа к данным как отдельный проект и имеете модульные тесты для запросов. Чтобы сохранить принцип SOLID, не смешивайте слой данных с api. Если вы только начинаете, EF Core может быть лучше EF6 в основном из-за скорости и мобильности.

понимание и отладка больше связаны с языковыми предпочтениями разработчиков. Я, конечно, нахожу, что LINQ гораздо сложнее использовать, чем SQL, но я программист баз данных.
@hlo ваш вклад - большая помощь для моей архитектурной борьбы! Я пометил в качестве ответа, так как я получил достаточно вдохновения от вашего ответа и комментариев других, чтобы продолжить (я признаю, что мой пост был немного широким и затрагивал несколько вопросов, я лучше закрою его и открою новый вопрос, если я застрял с моим Проект) Большое спасибо всем! Поддерживайте хороший дух сообщества StackOverflow!
Я все еще заметил, что ядро EF работает медленнее, чем dapper. Поэтому я выбираю dapper, но каков будет профессиональный способ реализации Asp.net.core + Dapper + PostgreSQL с точки зрения архитектуры.