Должен ли я хранить жестко закодированные данные на уровне доступа к данным Entity Framework?

Question

У меня есть трехуровневое приложение, которое использует. NET Core EF в качестве уровня доступа к данным. Кроме того, у меня есть бизнес-логика c, в которой для выполнения операций CRUD с базой данных используется EF Dbcontext.

Сейчас я нахожусь в ситуации, когда я хочу иметь возможность объекты страны и государства, то есть:

public class CountryAndStates
{
    public string Country { get; set; }
    public List<string> States { get; set; }
}

Я решил не помещать эти данные в базу данных и, таким образом, жестко их кодировать, так как это данные c.

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

Однако я не уверен, что это хорошая идея. Поэтому я хотел бы знать, как это будет решаться оптимально с точки зрения архитектуры программного обеспечения.

Answer 1

Я собираюсь внести свои 2 цента на этом. Ваш уровень доступа к данным должен скрывать реализацию всех хранилищ данных: баз данных, файлов, вызовов внешних API.

Ваш BL никогда не должен напрямую использовать DbContext и даже не должен ничего знать о его существовании; потому что это делает ваш BL зависимым от детали реализации, которая тесно связывает ваш BL с вашим DAL ...

Что если вы решите больше не использовать Entity Framework?

Что если вы хотите включить другие хранилища данных, такие как json файлы или обращения к внешним интерфейсам API?

Вы видите, что вызов DbContext из вашего BL отрицает цель многоуровневой архитектуры.

Не говоря уже о том, что он нарушает несколько принципов SOLID design.

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

Кроме того, используя DbContext непосредственно из своего BL, вы смешиваете доступ к данным с бизнес-логикой c, которая нарушает инкапсуляцию и единственную ответственность.

Если вы разделяете и инкапсулируете свой DAL, вы можете добавить любое хранилище данных без необходимости переосмысления уровня бизнес-логики c.

Answer 2

Я хотел бы предложить то, что называется «Кэширование на стороне сервера», что является обычной практикой для работы с данными c.

Вы можете создать static Dictionary<string,List<string>> и инициализировать этот словарь в своем приложении. запуск при чтении данных из базы данных или любых других ресурсов (вы даже можете жестко закодировать данные, как вы упомянули).

Затем вы можете рассматривать и рассматривать этот словарь как datasource и добавлять функции на уровень доступа к данным. для доступа к словарю.

Очевидным преимуществом этого подхода является повышение производительности.

Answer 3

Вы можете сохранить данные в файле ресурсов на уровне приложения https://docs.microsoft.com/en-us/dotnet/framework/resources/creating-resource-files-for-desktop-apps

Или вы можете пересмотреть и создать объект БД для данных и кэшировать его на уровне приложения

Answer 4

Алекс - Тин Ле верна, но вот наука почему.

С точки зрения производства, процесс должен быть отделен от вашей спецификации (BOM). Заказ на производство содержит как процесс, так и акт выбора имеющихся в наличии компонентов.

Ваше действие контроллера - ваш заказ - который использует эти данные, должно поэтому ссылаться на конкретизированную гидратированную модель CountryAndStates до обработки действия пользователя. , База данных определенно не является словарем для внешних данных, которые могут быть получены из файлов или даже вызовов Google Web API. Храните эти классы в отдельной папке и пространстве имен из моделей баз данных, чтобы каждый класс компонента мог содержать свои собственные загрузчики, если это необходимо. Естественно, вы должны стандартизировать компоненты с помощью базового класса, чтобы ваш контроллер мог обрабатывать сбои загрузки.

Answer 5

Это зависит от того, как вы используете эти данные c.

Но я предпочитаю, чтобы DBContext всегда отражал именно вашу БД, так что это единственная ответственность. Следовательно, его проще поддерживать.

Затем я помещу эти данные c в папку "utils" в вашем слое logi c. Или даже поместите его в проект «utils», если у вас много проектов на бизнес-уровне.