I'm unsure as to what is the set-in-stone way to access databases

I have quite a deal of experience programing with VB6, VB.NET, C# so on and have used ADO, then SubSonic and now I am learning nHibernate since most of the prospective jobs I can go for use nHibernate.

The thing is, I have been programming based on what I have been taught, read or come to understand as best practice. Recently, someone through a spanner in the works and had me thinking. Up until now, I have been accessing the database(s) from both the core applcation and attached DLLs that I write.

What this persons said ends as follows and hence my question:

I can tell you that you wouldn't normally want to do this - an external class library shouldn't have access to the database

What I was trying to do was to have a shared/static class for nHibernate sessions that could be consumed in both the global scope of the app and from any dll. This class was to be in a "core" DLL which all dll开发者_如何学Cs and the application reference. Like I said I'm learning nHibernate so it may not be the way.

To say i'm questioning my database access methods is putting it lightly.

Can anyone put me straight on this?

Edit:

I suppose looking at what has been commented already, it depends on how the database is being accessed. I would tend never to put username/password credentials etc hardcoded in any DLLs for any means.

More specifically, my query is in relation to NHibernate's sessions. I have a static class, an helper class, which is called at application start and the new session is then created and attached to the current context, in the case of web applications, and then whenever I need the session I call "GetCurrentSession". This static class is in the "core" dll and can be accessed with any DLL etc that references. This behaviour is intended. My only question is is this ok? Should I be doing it another way?

---

A couple of reasons would be

1. Access to the database, how do you cover off username/password
2. sharing the DLL, a "bad" application may get hold of your DLL and link with it to get access to your database.

Saying this, if you have proper security on files, etc. then I would have thought using a DLL would probably be a reasonable way to go.

---

Assuming that the username and password are not stored directly in the DLL (but maybe passed as parameters, or passed as a complete connection object) this isn't so bad.

The possible bad practice here might be accessing the same database for the same purpose from different places - core app and DLL. This could get confusing quickly to a new developer, unless the separation is clear and logical.

Myself, I might try to move ALL (or almost all) data access to a DLL just for that purpose, then have the serious application logic (or as much as possible) in the core app or yet another DLL.