CODEWITHSUNDEEP
c#interfacereferenceproject
Sergey Rotbart
Sergey Rotbart

Reputation: 319

c# interface references

enter image description here

Hello everyone

Currently I have the following reference structure:

DSFinalProject have reference of "DAL" project and "DataStructure" project.

DataStructure have reference of the DAL project as well…

Now I want that DSFinalProject won't have reference to the DAL layer but will be able to use interfaces from that class.

Is there any way to "tunnel" the interfaces that are in the DAL project to DSFinalProject without actually making references between them?

Maybe using the DataStructure project? Or anything else?

Thanks in advance for any help :)

Upvotes: 0

Views: 587

Answers (3)

D Stanley
D Stanley

Reputation: 152634

The easiest way is to put them in DataStructure, which isn't too bad since anything that references the interfaces will need to reference DataStructure as well.

My vote would be to put them there until you run into a scenario when you need to have the interfaces in a separate assembly.

Upvotes: 1

AlSki
AlSki

Reputation: 6961

I don't believe that there is anyway to so what you ask. If you think about what happens when you serialise objects, you still need the assembly to provide the low level structure of how the fields are laid out inside the stream of data. It needs the code in the interface to say that the first 4 bytes are a double, etc.

So the only to do this is to move your interfaces into a new interfaces.dll which can be referenced by everything. You will see this pattern repeated in many examples including the EnterpriseLibrary.

However... you are making a classic mistake. Why are you splitting your code into so many projects? Projects really should be thought of as the run time packaging of our code, not a desing time segregation mechanism. By splitting into so many assemblies, you do three things.

  1. You slow your build system down, as the compiler does more work fetching the other assemblies.
  2. You slow down Visual Studio as it works harder to load up all the projects and keep the references between them. I once worked on a solution with 140 projects that took 15 minutes just to open (but I always got my morning coffee).
  3. You slow down the run time performance as DotNet has to search around for another 4k dll (thats the minimum, even for just one line of code). Try looking at the fusion logs or use SysMon to see just how much work is involved in this simple operation.

Take a look at this example Hints on how to optimise code do see what's going to happen as your solutions get more complicated.

Instead of splitting it like this, use namespaces instead, you will still have the seperation, but instead of having to use so many references, you now have control by the using statements inside your classes. You will easily see if you are using a DAL reference in a class designed to be in a DSFinalProject tier. You can just create a folder under the project and add your classes there instead. Get rid of all the projects and still have a properly tiered system.

As your solution grows, wait until you have at least two executables before you start introducing projects, and then consider the run time implications. If you are always going to load up two assemblies, merge them into one (I've seen some open source projects these days that use ilmerge to merge in third party libraries too).

Upvotes: 1

Rob P.
Rob P.

Reputation: 15091

I don't know of any way to reference interfaces (or anything else) inside the DAL project from DSFinalProject without having a reference to the project (or assembly).

You can move them to another project if you think it makes the dependencies cleaner - if you put the interfaces in the DataStructure project - you'd run into a circular reference where it needs DAL and DAL needs it.

Upvotes: 1

Related Questions