Новичок в Entity Framework и ORM, однако, возможно, есть уникальное обстоятельство, когда мы думаем о некотором рефакторинге того, как работает наше приложение.
Прямо сейчас мы используем архитектуру распределенного кеша в памяти, в основном как базу данных в памяти, довольно неэффективным и подверженным ошибкам способом, из-за чего синхронизация с постоянными данными и даже объектами в кеше не согласована.
Мысль состоит в том, чтобы несколько вернуться к ядру и либо интегрировать какую-либо форму ORM, например Entity Framework, либо вручную создать хранимые процедуры в SQL, чтобы ввести данные, необходимые для создания сложного класса.
В качестве примера предположим, что у нас есть класс SomeDashboard, который будет иметь множество свойств, установленных на основе запрошенного Dashboard (хранящегося в SQL), но затем множество списков объектов, связанных с Dashboard, таких как Products или Reviews, и т. д. Можно написать хранимую процедуру, которая будет использовать один запрос к БД, который будет извлекать несколько наборов результатов для создания всех этих списков и значений объектов.
Было бы лучше создать хранимую процедуру для этого или создать несколько хранимых процедур для получения данных по частям (что означает большее количество вызовов SQL) или использовать Entity Framework для поштучной обработки всех объектов вместе?
Что-то, что будет изменчивым, из-за чего это нужно будет перестраивать довольно часто; беспокоит масштабирование базы данных с таким количеством подключений и таким количеством запросов каждый раз, когда мы создаем объект.
Возможно, в этом достаточно смысла, чтобы дать какое-то направление; Я знаю, что это расплывчато, в лучшем случае.
Другая часть вопроса, связанного с Entity Framework, будет заключаться в следующем: насколько сложно сопоставить все с существующими базами данных и классами?
На высоком уровне ... ощущение, что интеграция распределенного кэширования в памяти была не очень хорошо продумана и выполнена таким образом, чтобы «упреждающе оптимизировать», что вызывает больше проблем, чем решает; поэтому возвращение к истокам и интенсивное использование SQL, а затем выборочная интеграция кэширования там, где оно может понадобиться, и когда производительность с SQL становится проблемой, кажется лучшей идеей.
