views:

101

answers:

2

I write in-house software for a company.

I always want to leverage OOP techniques as best as I can. In this thinking, I want to create a Data Access Layer (DAL) isolated in its own .DLL.

What can I do to limit the access of the DAL DLL to only my business logic layer DLL?

The last thing I need is someone in the company with a little programming knowledge plus access to the system (via Active Directory) to install .NET Express, reference my .DLL, and start firing off data access code outside of the real system. Are there any .NET mechanisms I can employ to limit a DLL to be used only by a pre-selected host application/DLL?

+7  A: 

The easiest way to limit access from a code perspective is to use friend assemblies. You can make all of the types in your Data Access Layer DLL Friend / Internal. Then only add your Business Logic Layer components as friends and they will be able to use the types. Anyone else in the company will not since they don't have DLL's with internal access.

Documentation - http://msdn.microsoft.com/en-us/library/bb384772.aspx

JaredPar
-1 That would not work. Marking a class as Internal means that only classes within the SAME assembly have access to it. Other assemblies which reference the DLL would not. He is specifically asking for a way that he can limit usage of a DLL to a separate assembly that he wants.
Nick
@Nick, did you read the link I posted? Friend assemblies provide this exact behavior.
JaredPar
My fault there... thought it was talking about simply using the internal keyword on the classes.
Nick
@Nick, no problem
JaredPar
Excellent! I didn't know about the concept of assembly scoping like this. Thanks.
HardCode
+1  A: 

You could probably make use of the Application Licensing framework build into .NET using the LicenseProvider class. Depending on how you implemented it, having a DLL would not be enough to use your library... they would also need some sort of license file, or provide a license key. Here is a good article on how to start using it.

Nick
+1 for a good alternative perspective. However, it would be overly complex for in-house software. But a nice idea!
HardCode