Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Entity Framework: Naming conventions/suggestions for EDMX file and entity class?

I´ve not had much contact with Entity Framework yet and therefore I´d like to hear some guys with experience.

I´ve got an MVC project and my DataAccess lies in a different project where I want to place my EDMX file.

So how would I like to name this file? Per default it is "Model1.edmx" but in the context of MVC I don´t feel comfortable with this name. Is it really a Model? I tend to call it "DbModel" or something to indicate that it is database related stuff.

And how do you guys call the entity class? I think I like the EF typical name "DbContext".

So within my controllers I´d have something like

public class WorldController : Controller
{
    DbContext db = new DbContext();

    public ActionResult Own()
    {
        var allContinents = db.Continents;
        [...]
    }
}

Sorry for being fussy but I really do care about naming.

like image 460
timmkrause Avatar asked Mar 22 '12 10:03

timmkrause


People also ask

What is EDMX file in Entity Framework?

An . edmx file is an XML file that defines an Entity Data Model (EDM), describes the target database schema, and defines the mapping between the EDM and the database. An . edmx file also contains information that is used by the ADO.NET Entity Data Model Designer (Entity Designer) to render a model graphically.

Which file represents entire database entity in EDMX?

TestModel.tt file contains all your SQL table class files with all the entities.

Do we need EDMX XML file for EF code First approach?

Code first approach lets us transform our coded classes into database application, which means code first lets us to define our domain model using POCO (plain old CLR object) class rather than using an XML-based EDMX files which has no dependency with Entity Framework.


1 Answers

It is good to care about naming!

How to do it depends on the composition your application. Let's say you have a web application for registering UFO sightings, to name something common. If there is a separate part of your db (maybe a separate schema) containing users, roles and permissions, you could create a context named AuthorizationContext, and for the business part a context named UfoDbContext.

I mean, if there are clear aggregates with no or little overlap you could create separate contexts for them with clear names. If one context fits the bill, I would still give it some meaningful name (not DbContext) that relates to your application domain.

There are people (I'm not one of them) that like to work with one context per application "column" (db to UI) or "user story". Meaningful names are even more important then.

like image 50
Gert Arnold Avatar answered Oct 20 '22 17:10

Gert Arnold