1

I have an assembly that contains base objects for my Business Objects, and then another assembly that is automatically generated and populated with classes based off a database schema. The classes in the latter assembly all inherit from a class in the former.

The idea I had was that I could reference the generated assembly from other projects, and 'not' the assembly with the base objects thus hiding some of the implementation details and prohibiting people from using these objects.

Unfortunately, I am realizing that I cannot use any of the functionality built into the base unless I reference it as well. So my question is: Is there anyway around this, and if not then is there a design pattern that addresses this that I should be using?

Brandon Moore
  • 8,590
  • 15
  • 65
  • 120

2 Answers2

3

Question sounds slightly backwards. You are hiding your business/domain layer with your data layer? Generally that would be the other way around.

Either way. The issue sounds like you have:

  1. Assembly A

    class Bar

  2. Assembly B

    class Foo : Bar

Assembly C must reference both A and B to use Foo.

The design principle to follow would be to favor composition over inheritance.

Rather than Foo inheriting from Bar, Foo could contain an instance of Bar and expose what methods make sense for Foo. This is all assuming that Foo is not actually a specialized version of Bar.

Jacob
  • 8,278
  • 1
  • 23
  • 29
  • 1
    I'm not sure you are understanding correctly, and maybe I didn't communicate clearly. But the problem isn't that assembly C must reference A & B to use Foo, the problem is that assembly C must reference A & B to get the functionality of Bar when using Foo. – Brandon Moore Feb 17 '12 at 03:01
  • Also, A would be the data access layer and B would be the domain layer. Well, that's not technically 100% true of the way my code is now but generally speaking it is. And I would prefer to be able to reference B without having to reference A if possible. You make it sound like I meant it the other way around though... – Brandon Moore Feb 17 '12 at 03:08
  • 1
    @BrandonMoore I think I may have been confused by the wording. However in the example above assembly C would have to know about both Foo and Bar to use Foo. To not reference assembly A, Foo cannot inherit from a class in assembly A. – Jacob Feb 17 '12 at 03:12
  • @BrandonMoore see http://stackoverflow.com/a/3626965/226006 . Similar problem, solution like I've described. – Jacob Feb 17 '12 at 03:14
  • Yeah, I just realized that after trying to compile. Before I assumed it was going to let me because intellisense didn't complain. – Brandon Moore Feb 17 '12 at 03:16
1

If you really don't want to expose the base classes to others (think extensibility), then you probably should move the bases into the same assembly as the concretes.

If you still need the assemblies separated, you can still make the bases internal, and then set the InternalVisiblesToAttribute on the base class assembly:

(In AssemblyInfo.cs)

using System.Runtime.CompilerServices;

[assembly:InternalsVisibleTo("ConcreteClassAssembly")]
Steve Czetty
  • 6,147
  • 9
  • 39
  • 48