This might be a stupid question but I’ve never created a class library before
The reason I don’t want to be connecting to a database through the class library is error handling.. should I just leave the errors to throw back to whatever code is using the class library? should I handle it there? or should I just leave it completely and take the whole database object out of the library, creating it seperately/ copying and pasting every time I want to use it.
This is a small project with only 12 classes, all under 200 lines and is only going to be used on in house company applications. I’m probably going to be the only one using it to develop with unless I leave and someone needs to make changes to the applications.
It’s c# if that makes even the slightest difference?
No, you shouldn’t.
You should pass in connection strings as a dependency, or use ConfigurationManager to pick them up from the application configuration.
Hard coding them means that you can’t change them without recompiling the libraries.
The reason I don’t want to be connecting to a database through the class library is error handling
False logic there. You should handle database issues in that data access layer (which can be in a class library) – other logical and business issues should be handled in the business logic layer (which can also be its own class library).
Exceptions that are not handled bubble up.
1
Normally one puts everything related to data access in a data access layer (DAL) which would be a separate DLL-file. Creating this class library is pretty straight forward. Just remember to add a reference to your newly created project in you main project.
Whether or not you deal with exceptions in the DAL or you let the business logic layer deal with it is more a matter of taste. I personally prefer dealing with return codes that indicate success or failure rather than surrounding all calls to the DAL with try/catch.
Keeping data access in a different class library will make your code more manageable, even if you decide to scale up the project. In a deployed product, updates to the logic of the DAL can be as easy as swapping a DLL file as opposed to update the whole program.