How should I name database wrapper object?

Question

For my CMS application I'm writing a DLL that I will include into my projects. That DLL will include functionality like retrieving all news for a specific project.

For instance, my database contains a table called News. By using the Entity Framework 4 I have a automatic generated class called News. I do not want my DLL methods return this object rather than a wrapper class, that only contains properties.

How should I name this wrapper class? For now I've always appended the word "Container", but over the time I do dislike this suffix. Meaning, I would now name this class NewsContainer.

Of course I could name this wrapper class also News. This would work because I'd have two classes in two separate namespaces, but I'd rather not name two different classes the same. Is is ok, two name to different classes the same? I'm asking this, because News would actually the best name fit.

Edit: I do manually map the properties between my own wrapper class and the automatic generated entity framework class, if that is of any importance.

Ambidexterity

The "News" class in question here is your domain model class or your object context? You said you wanted to return a class that contains only properties so I wasn't clear which you were talking about since the domain model generated should already have "just properties." – Warford

Well yes, both classes only contain of properties. But somehow I feel like it is not good to expose the object context class into other projects. For instance I could add additional properties to my own class. I guess that is also possible with the EF4, but I haven't figured it out, but that relates more to this question #3631153 – Ambidexterity

Answer 1

I'd agree with your initial naming of your wrapper/DTO class as News. Keeping them in separate namespaces with the same names is perfectly fine. That's part of what namespaces are for: to reduce collisions in naming.

I'd sketch out something like this

namespace MyCmsApp.Models
{
    public class News {
        public string Title { get; set; }
        public string Body { get; set; }
        public string Author { get; set; }
    }
}

I'd then have the DataLayer return only types within the MyCmsApp.Models. In other words, as you were suggesting, the EF generated classes don't cross over into your app.

Side note: why are you trying to avoid using the EF classes? Would you consider code-first and/or Model-First design? In those scenarios, the database bends to your application's object model design.

Macedonian

Model-first because I've always created applications that way. I'm still having trouble using the Entity Framework for more than the DataContext. I have trouble getting started, as you can witness here: #3701137 I'm missing a nice book or online tutorial? Can you recommend one? – Ambidexterity

Answer 2

It sounds like you are creating DTOs, in which case it could be something like NewsDto or NewsDTO?

Penniepenniless

Answer 3

Sidebar: “News” is already troublesome because it is a reserved word and it has odd pluralisation issues i.e.: new new,new news, newnews, new NewNews().

Ad hoc terminology requires additional steps to interpret the intent or context, which makes working with the design confusing to you as well as others.

From your example, are you referring to a NewsArticle, NewsFlash, NewsSnippet or NewsEntry? Does a Project have a News? Is there such a thing as a NewsContainer? In my mind, a NewsWrapper might be a plastic bag or even an elastic band.

Roughly translated n-tier might look something like...

UI.ProjectNews (presentation)
DTO.ProjectNews
POCO.ProjectNews (logic)
DTO.ProjectNews
EF.ProjectNews (data)

From my experience, the best way to design any database schema or class design is to refer things just like you would in normal conversation. Real world terminology greatly contributes to productivity, development time, maintenance and collaboration.

Doner