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

Question

У меня довольно большой опыт программирования на VB6, VB.NET, C # и так далее, и я использовал ADO, затем SubSonic, и сейчас я изучаю nHibernate, так как большинство предполагаемых заданий я могу использовать для использования nHibernate.

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

То, что сказал этот человек, заканчивается следующим образом, и, следовательно, мой вопрос:

Я могу сказать вам, что вы обычно не захотите этого делать - внешняя библиотека классов не должна иметь доступа к базе данных

Что я пытался сделатьдолжен был иметь общий / статический класс для сессий nHibernate, который мог бы использоваться как в глобальной области приложения, так и из любой библиотеки DLL.Этот класс должен был находиться в «основной» DLL-библиотеке, на которую ссылаются все библиотеки и приложение.Как я уже говорил, я изучаю nHibernate, так что, возможно, это не так.

Сказать, что я подвергаю сомнению мои методы доступа к базе данных, - это просто.

Может кто-нибудь прямо сказать мне об этом?

Редактировать:

Полагаю, если посмотреть на то, что уже было прокомментировано, это зависит от того, как осуществляется доступ к базе данных.Я бы никогда не стал вводить учетные данные имени пользователя / пароля и т. Д. В какие-либо библиотеки жестко закодированными для каких-либо средств.

Более конкретно, мой запрос связан с сеансами NHibernate.У меня есть статический класс, вспомогательный класс, который вызывается при запуске приложения, а затем создается новый сеанс и присоединяется к текущему контексту, в случае веб-приложений, а затем, когда мне нужен сеанс, я вызываю «GetCurrentSession».Этот статический класс находится в "core" dll и может быть доступен из любой библиотеки DLL и т. Д., На которую есть ссылки.Такое поведение предназначено.Мой единственный вопрос, это нормально?Должен ли я делать это по-другому?

Answer 1

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

Возможная плохая практика здесь можетполучать доступ к одной и той же базе данных для одной и той же цели из разных мест - основного приложения и DLL.Это может быстро запутать нового разработчика, если разделение не будет четким и логичным.

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

Answer 2

Пара причин будет

1. Доступ к базе данных, как вы закрываете имя пользователя / пароль
2. общий доступ к DLL, «плохому» приложению может достатьсясвою DLL и ссылку на нее, чтобы получить доступ к вашей базе данных.

Сказав это, если у вас есть надлежащая защита файлов и т. д., то я бы подумал, что использование DLL, вероятно, будет разумным способомидти.