0

REST APIs in virtually all languages use methods named Get to get GetById(int id).

Is it ok to use this convention for repositories?

Let's say I have a Professions repository for the sake of example.

Is writing _professionsRepo.Get(profId)intuitive or would most programmers rather see _professionsRepo.GetById(profId) or even _professionsRepo.GetProfessionById(profId).

(Though I feel the distinction between the last two is a debate of its own).

1
  • It depends. If your repo is a simple CRUD wrapper, and only returns Profession instances, then Get is probably fine. If your repository is actually designed to return domain model objects (perhaps with prefilled subentities in the aggregate) ready to be consumed by, or fulfill, a use case, you may have several such methods with different semantics, and in that case you'd want to reflect that somehow. E.g. _professionsRepo.GetForAssesment, or even _professionsRepo.GetViaQuery(useCaseSpecificQuery). – Filip Milovanović Nov 13 '20 at 20:49
1

This is a very subjective question.

One the one hand, Profession Get(int id) should be obvious. The method is called "Get" (as in "to retrieve something"). The parameter is an int named id (as in "an identifier whose type is integer"). And this method returns a Profession. If the method is called "Get", returns a Profession and receives an integer argument named "id" then inductive reasoning tells us this gets a profession by Id.

This leads me to believe that Profession Get(int id) is sufficiently descriptive enough to infer how this method should be used.

Except for the teammates who do not look at the full signature of a method. On my team, this apparently is nearly all teammates.

I detest repeating concepts in the names of things. If the class is named ProfessionRepository and it has a method named GetProfessionById which returns a Profession and receives a professionId as a parameter, my blood pressure instantly boils over. Why... why do we need so much repetition!?

class ProfessionRepository
{
    public Profession GetProfessionById(int professionId) { ... }
}

// later on when using this class:

public ActionResult View(int id)
{
    var profession = _professionsRepo.GetProfessionById(id);

Seeing code like this makes me want to cry.

Now take this:

public class ProfessionRepository
{
    public Profession Get(int id) { ... }
}

// later on when using this class:

public ActionResult View(int id)
{
    var profession = _professionsRepo.Get(id);

This is concise without being terse. The names of all things in the current scope are meaningful, and people should be using inductive reasoning to make intelligent assumptions about application behavior. But as I said before, many of my teammates don't use inductive reasoning like this.

Naming things is always hard, and always subjective.

Consult your teammates about this, and come to a compromise.


Totally unrelated: I've noticed a split between "coders" and people who can engineer things. Inductive reasoning is that fork in the road that separates people who can write code from people who can engineer software systems.

1
  • I am relatively new to this board (I mainly live on stackoverflow), but these types of subjective questions are what eventually makes up readable code imo. Sometimes it's just good to get the prevailing general opinion too. Ty for the rationale. – VSO Nov 13 '20 at 23:33
1

It's all about semantics and what you assign to it.

Whatever you choose, it's important that you are consistent within the code base. So if you call 'get by id' simply Get for one entity, your other entities' method names and semantics better mirror that behavior.

If you have to get something other than by id but the type is the same (int in your case) then you should assign more semantics to this new method by giving it a more descriptive name.

Not on repository but on higher abstraction (like a service) methods we used to have retrieve and also a get. The semantics to retrieve would be that it would automatically throw an exception if something was not found while get would return null and not blow up and this gave a good balance for different client code to pick from.

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.