In our solution we have a couple of projects, a project for data layer, service layer, business layer. etc.

Inside the business layer, we use models to transfer data from classes to classes. Is it good practice to make these models and all their properties, methods and constructors internal?

I just realised, if a class is internal, making the properties and methods internal does not do anything.

  • 2
    if they are not supposed to be used outside of the library... yes
    – Ewan
    Aug 30 '19 at 10:59
  • 2
    Possible duplicate of Why not make everything private or public?
    – gnat
    Aug 30 '19 at 11:10
  • If everything is internal, how do you call the code?
    – Helena
    Aug 30 '19 at 14:31
  • 1
    Note that you can make them internal by omitting an access modifier, which I do on top-level classes and structs in my applications; then explicitly use either public or private for fields and methods.
    – Erik Eidt
    Aug 30 '19 at 16:33
  • @helena: Within assemblies. The boundary is defined between assemblies. Aug 31 '19 at 15:34

Yes. It is good practice to make internal classes internal.

Let's not beat around the bush. The whole point of the internal keyword is to stop stuff being used outside of the assembly. If you have classes which are specific to that assembly and not exposed outside of it. Then mark them internal.

If you don't, then another developer might start using those classes and then you have something else to worry about if you make changes to them.

Now you can argue "Its OK to skip that because I know not to use the class outside of its designed use!" fine. But its not "best practice" to do that. It's just corner cutting.


It's contextual.

Your question is the programming equivalent of asking if you should lock every door in your house.

In general, locking your doors is a good approach which everyone will recommend on principle, but if you start locking every single door in the entire house, you're going to end up frustrated and walking around your house is going to be slow and cumbersome.
There needs to be a line of reasonability here. Overdoing or underdoing it each come with their own drawbacks and you need to see what is relevant for you (it's mostly a conflict between strict access control vs easier development).

Inside the business layer, we use models to transfer data from classes to classes. Is it good practice to make these models and all their properties, methods and constructors internal?

Since the only purpose of the models is to travel around inside the same assembly, it makes sense to make these internal. Especially if these can be abused when exposed to consumers, but I surmise that this might not be the case for this particular scenario.

Is it good practice to make everything internal in C#?

Ehhh, I find it an arguable point. I definitely see the reasoning behind a "make everything internal by default" approach, but then again I also don't quite see the benefits gained from policing this in most projects I've worked on.

It's a matter of approach and a question of whether you find the effort of enforcing this rule to be worth the potential gains. Some considerations:

  • There's no discernable benefit to doing it in small home projects that only you use.
  • There's a notable benefit to doing it in projects that are exposed to consumers (it limits their access to things they actually care about).
  • While it can be beneficial for the business (rigorous access control for security purposes) ...
  • ... it can also be detrimental, e.g. incurring extra development time from developers who reinvent the wheel because they didn't know the wheel already existed somewhere else (as an internal). This might set a precedent for developers starting to look everywhere for something they need because it may have been hidden behind an internal access modifier. That sounds innocuous but if it becomes the standard it will be a drain on development time.

This is something you're going to have to evaluate for yourself. There is no "one approach fits all" solution here.

  • oof, thats a dodgy analogy
    – Ewan
    Aug 30 '19 at 11:16
  • @Ewan: The main takeaway is that it's mostly a cost/benefit analysis. Doing it (or not) brings pros and cons and it's a matter of deciding which pros and cons you'd prefer.
    – Flater
    Aug 30 '19 at 11:34

Yes if you want a library that is self described in which the developers know this functionality that is exposed publicly is the right one to use otherwise you will introduce breaking changes if you go back at a later time and mark publics as internal or private.

Another alternative if applicable is to wrap the dll functionality into an web api then it’s easier to maintain and control exposed functionality from a centralized unit of code and versioning becomes a non issue and your not passing dlls or nugets around, this could introduce some network latency if not on a local subnet or a slow network, and this doesn’t always fit the bill since you will also need authentication and authorization in many cases but if it is all internal you could like bypass that.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.