I'm in a little need of names clarification. First a brief description of my position. I prepare as debutant giving a junior developer job descriptions, which also provided another perspective on how important communication is, and to put it beyond doubt.

Simply; I like to understand what he mean with "Context" and I like to give a adopted description of what a POCO is. Now, this is not the exactly problematic words. We haven't even spoken yet. I describe it more as the semantic problem and focus on data and IoC, because there is the place we're going to met (He = GUI, I'm BL).

I give a manual-typed sample just as a reference for naming different part of it. Some terms are local to a Manufacturer or tool and some are used more Generic, which I prefer the latter.

// Poco, Model?
public class Customer
    public int CustomerId { get; set; }
    public string Name { get; set; }

// A short sign of repository pattern
public class CustomerContext

   // Is this a context or even a entity? 
   List<Customer> cust;
   public CustomerContext()
      cust = new List<Customer>();
      cust.Add(new Customer() { CustomerId = 1, Name = "Doe" });
      cust.Add(new Customer() { CustomerId = 2, Name = "John" });
      cust.Add(new Customer() { CustomerId = 3, Name = "Zelda" });
      cust.Add(new Customer() { CustomerId = 4, Name = "Kim" });

   public IQueryable<Customer> Get()
      return cust;

*What terms fit best? *

Are 'Customer' a Model (tooked from MVC)? Does we, simply put, mean the same with POCO?

What do I call the sample typed data above? Mocks? Simply "Data"?

What do I call the object CustomerContext? A repository? A Context? Is it an Entity?

Are there other terms that have escaped this scope?

It appears common to write about repositories and generics, even though fell into a scope of a manufacturer (where i.e. 'Entity' commonly means Entity Framework). A strong indication of what terms means what (and when), would be of help.


2 Answers 2


Are 'Customer' a Model? Which it appear to be called in MVC?

Yes, it can be called a Model. Often in MVC, the Model is not simply a single business entity - it could, for example, be a collection of multiple entities and various user settings rolled into one, everything the View needs to be able to do its job.

Does we, simply put, mean the same with POCO?

Yes, it's a POCO, because you are not implementing any specific interfaces, or inheriting from some entity framework.

What do I call the static typed data (in such case)? Mocks? Simply "Data"?

I would probably call it test data. It's kind of hard to call it a "mock" since it seems to be your primary implementation at this point. I've never encountered the word mock being used outside the context of unit testing, what you have here seems to be more in line with the term "fake" (see Wikipedia's article on these particular terms).

What do I call the object CustomerContext? A repository? A Context? Is it an Entity? I often confuse these terms with what I mean.

It looks like it's the beginnings of a Repository Pattern.

As an aside, List<Customer> cust; is a fairly bad naming convention - try not to use abbreviations. It will be confusing when the Custodian, Custard and other similar classes start making appearances in your code :)

  • 1
    I was about to answer something similar. So +1 for the answer. I would also add that Customer being a data object, should be also final (no setters, set values in constructor and use getter to retrieve them). You should also probably consider programming to an interface, so that business logic implements the interface and the UI uses that same common interface. This also helps respecting the Dependency Inversion Principle (see the SOLID principles for more details). Jul 25, 2012 at 12:44
  • @PatkosCsaba Thank's. Feel free to add an own comment. You are adding interesting and important info to readers! Looking at my own scenarion, there are a DI perspective to this, not in scoop of this question though. Jul 25, 2012 at 12:57
  • @Jonas: I understood that you refer to the Customer class as mock? Customer is a data object, thus it has absolutely no behavior. If you read again the definition of mocks, they replicate behavior. If you would program to an interface, in your case, you would have real implementation of the interface, your CustomerContext (or should I say CustomerRepository) and another one MockCustomerRepository which would have the same methods but provide predefined data. This way, when you build the UI, use the MockCustomerRepository as the implementation of the interface. Jul 25, 2012 at 13:23
  • @Jonas: these are the comments. Did you want to say that I should formulate a separate answer? Jul 25, 2012 at 13:24
  • Patkos, I mean a separate answer, Jul 25, 2012 at 15:52

Are 'Customer' a Model? Which it appear to be called in MVC?

In my opinion: Customer, is a DTO (Data Transfer Object). As it is right now, there's no logic or behaviour built into Customer - this is generally what separates it from being a business entity, domain entity or anything of that sort. Because of that, I wouldn't necessarily call it a model exactly, or I'd say that your model is anemic (or you've just over-simplified the example and this doesn't apply).

Does we, simply put, mean the same with POCO?

This you really could have just looked up first. Either way, POCO is often used in the context of an ORM. It simply means that you aren't forced to inherit some base entity type that is required by your persistence framework.

What do I call the static typed data (in such case)? Mocks? Simply "Data"?

As Daniel B states, it's test data. A mock is an object where you provide the expectations that the object should return (at run/test time). A Fake is roughly the same thing, except that the expectations are often provided at design time. There's a good writeup here.

What do I call the object CustomerContext? A repository? A Context? Is it an Entity? I often confuse these terms with what I mean.

Based on all of your questions, I suggest some reading/research:

And, last, and most important of all: the major benefit of design patterns is that they provide the ability to communicate about code at a more efficient and more abstract level. I highly suggest a few good patterns books as this is exactly the problem you're having. There are many questions on the SE network that have wonderful answers. For example.

  • Simply put; The terms 'Repository' and 'Context' are terms used when working on the actual patterns, not elsewhere? Jul 25, 2012 at 13:33
  • @Jonas: As programming constructs, the terms Repository and Context are themselves patterns. You can use the terms with meaning outside of that context, but that's not what we're talking about here. Jul 25, 2012 at 17:23
  • When are we named them outside this context? The question is not really about the implementation of design patterns either, but sorting out when the different terms are used. Jul 25, 2012 at 17:59

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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