Мне нужно создать приложение, в котором меня просят создать постоянный слой в приложении. Приложение находится в .net. Я создал бизнес-уровень и уровень представления, но не знаю, как и почему мне следует создавать постоянный уровень.
Я погуглил и узнал, что постоянный слой используется для хранения и извлечения данных, как правило, из базы данных.
Кто-нибудь может объяснить подробно?
причина для создания DAL (уровня доступа к данным) или любого другого промежуточного уровня между ядром базы данных и логикой бизнес-приложений заключается в том, что, добавляя этот промежуточный слой, вы изолируете остальные/верхние уровни приложения от конкретное ядро базы данных/технологии, которые вы используете прямо сейчас.
Это имеет несколько преимуществ, таких как более простая миграция на другие механизмы хранения, лучшая инкапсуляция логики базы данных в одном слое (более простую замену или модификацию позже в зависимости от того, насколько хорошо вы спроектировали свои межуровневые интерфейсы и т.д.)
посмотрите мой ответ здесь, это пример ASP.NET MVC и EF, но структурирование решения и проектов фактически не зависит от технологии: MVC3 и Entity Framework
Также прочитайте несколько статей, чтобы лучше понять этот вопрос, например: http://www.developerfusion.com/article/84492/net-and-data-persistence/
уровень прочности, иначе известный как уровень доступа к данным или другая терминология.
Он разделяет кишки получения и сохранения данных с бизнес-уровня. Причина, по которой вы это делаете, - это то, что ваша бизнес-логика (часть приложения, которая делает тяжелую работу для обработки данных) не привязана к определенному типу источника данных.
Уровень данных должен быть записан для конкретной базы данных. Поэтому, если вы используете MySQL для доступа ко всем своим данным, вы будете писать DataLayer для этого.
Если в какой-то момент вы решите перейти на MongoDB, вместо этого перепишите все ваше приложение. Вы можете переписать только части доступа к данным, чтобы получить данные от MongoDB. Поскольку бизнес-логика не заботится о том, как вы получаете данные, только то, что вы делаете, оно и уровень Presenation могут оставаться неповрежденными.
Надеюсь, что это поможет.
В очень простых терминах уровень сохранения - это способ использования SAVE и RETRIEVE, который использует ваше приложение.
Простой пример: у вас есть класс, который представляет человека (имя, возраст и пол). Пока приложение работает, оно сохраняется в памяти. Но, скажем, вам нужна эта информация, если вы снова закрываете и открываете приложение. Ну, вам нужен способ СОХРАНИТЬ этот человек, а затем снова RETRIEVE. В этом месте появится слой персистентности и напишет ваш человек где-то "постоянным".
Это может быть база данных, плоский файл, реестр в зависимости от срока службы и требований и т.д.
В ваших уровнях персистентности вы выполните операции CRUD (Create, Read, Update, Delete). Часто против базы данных, чтобы вы Создать новый человек (Fred Bloggs). Скажем, что они меняют свое имя, другой пользователь вашей системы может прочитать запись и перейти на Fred Miggins и Обновить базу данных. Затем этот клиент покидает страну, чтобы вы Удалить.
Persistence = чтение/запись/удаление записей на диск или базу данных.
Слой = изоляция и т.д.
Persistence Layer = обычно означает изолировать логику чтения/записи/удаления от бизнес-логики. в идеале путем размещения нескольких (или отдельных) точек взаимодействия между бизнес-логикой и модулями персистентности.
Я думаю, что это что-то, что мы все сделали (за исключением диска, db и т.д.), это просто фантастический академический термин, они просто просят нас:
Приветствия,
Если вы где-то не сохраняете свои данные, его снова не будет, когда ваше приложение будет открыто снова. Вы можете сохранить его в базе данных, как вы сказали (SQL, Oracle, PostGRE и т.д.), Или непосредственно на диск (сериализация в двоичном формате или обычный текст и т.д.).
Использование слоя для этого - хорошая практика. Он уменьшает сцепление (т.е. Код спагетти) и упрощает техническое обслуживание.
Я предлагаю вам прочитать о Hibernate и его кузенете .NET, NHibernate.