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.
0
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 🙂
5
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:
- Repository Pattern
- Context Pattern
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.
3