0

My situation is very simple. I have a class A, called through WCF service, which delegates it works to several 'helper' classes. These 'helper' classes are obviously internal. The problem is that I don't want that someone may call these classes directly. I would like that they always call the class A. This means that I need a 'namespace visibility'. I think that I can simulate it by making the 'helper' classes private (so I will include them in A, which will be split, thanks to the partial keyword, into several files (one per helper class)). What is your opinion on that solution ? Is it very dirty ?

Thanks in advance.

Improve this question

3 Answers 3

Reset to default
2

If the helper classes are internal, code outside the assembly won't be able to call into them anyway. Do you really not trust the rest of the code in your assembly?

There's no such thing as namespace visibility in .NET, although I agree sometimes it would be useful.

I would say that using partial to effectively make one giant class would be a pretty ugly solution. I'd just leave it at internal visibility and use normal code review processes to avoid calling into the helpers from elsewhere. Heck, you may even find that the helpers are genuinely useful elsewhere (or at least some bits of them).

Improve this answer
Sign up to request clarification or add additional context in comments.

Comments

0

Yes it would be a ugly solution. The practical way would be to only include class A and other helper classes in a separate assembly with A being public and the helper classes being internal. Do you really have a legitimate concern that other classes in the same assembly should not be able to use the helper classes. Generally an assembly is a structural unit and created by one team.

Another option (if you want to resuse the helper classes) is to put all internal helper classes in one assembly and then use the InternalsVisibleToAttribute to open this classes for use from e.g. AssemblyA that has class A.

Improve this answer

Comments

0

For smaller solutions, you should be OK with splitting your assembly when you need the encapsulation.

But for very large solutions (>100 projects), you might be forced to find alternatives, as visual studio starts behaving badly once you pass 150 projects - build times soar and you start running out of memory.

This has sadly not improved very much in VS2010.

Improve this answer

Comments