8

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.

Improve this question
9
  • 2
    if they are not supposed to be used outside of the library... yes Commented Aug 30, 2019 at 10:59
  • 2
    Possible duplicate of Why not make everything private or public? Commented Aug 30, 2019 at 11:10
  • If everything is internal, how do you call the code? Commented Aug 30, 2019 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. Commented Aug 30, 2019 at 16:33
  • @helena: Within assemblies. The boundary is defined between assemblies. Commented Aug 31, 2019 at 15:34

3 Answers 3

Reset to default
10

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.

Improve this answer
6

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.

Improve this answer
3
  • 2
    oof, thats a dodgy analogy Commented Aug 30, 2019 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. Commented Aug 30, 2019 at 11:34
  • One could do the same argument in an apartment building, rather than single rooms in my own apartment. I'd even argue, that the single rooms in my apartment comparison better refers to using private over internal, while different apartments in an apartment building refer to using internal over public. Only the shops on the ground floor you want to keep public, because they are for everyone's use. But single living apartments should stay internal. Also a good reference here is "hiding complexity to reduce cognitive load for others" (Team Topology, Continuous Delivery). Commented Aug 24, 2022 at 7:14
0

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.

Improve this answer

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.