Entity Framework: соглашения об именах/предложения для файла EDMX и класса объектов?

У меня еще не было большого контакта с Entity Framework, и поэтому я хотел бы услышать некоторых ребят с опытом.

У меня есть проект MVC, и мой доступ к данным находится в другом проекте, где я хочу разместить свой файл EDMX.

Итак, как бы я хотел назвать этот файл? По умолчанию это «Model1.edmx», но в контексте MVC мне не нравится это имя. Это точно Модель? Я обычно называю это «DbModel» или как-то так, чтобы указать, что это связано с базой данных.

И как вы, ребята, называете класс сущности? Мне кажется, мне нравится типичное имя EF "DbContext".

Итак, в моих контроллерах у меня было бы что-то вроде

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

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

Извините за суетливость, но я действительно забочусь об именах.


person timmkrause    schedule 22.03.2012    source источник


Ответы (2)


Хорошо заботиться об именах!

Как это сделать, зависит от состава вашего приложения. Допустим, у вас есть веб-приложение для регистрации наблюдений НЛО, если назвать что-то обычное. Если есть отдельная часть вашей базы данных (возможно, отдельная схема), содержащая пользователей, роли и разрешения, вы можете создать контекст с именем AuthorizationContext, а для бизнес-части контекст с именем UfoDbContext.

Я имею в виду, что если есть четкие агрегаты без перекрытия или с небольшим перекрытием, вы можете создать для них отдельные контексты с четкими именами. Если бы один контекст соответствовал всем требованиям, я бы все же дал ему какое-нибудь осмысленное имя (не DbContext), относящееся к домену вашего приложения.

Есть люди (я не один из них), которым нравится работать с одним контекстом для каждой «столбца» приложения (от БД к пользовательскому интерфейсу) или «пользовательской истории». Значимые имена еще важнее тогда.

person Gert Arnold    schedule 25.03.2012
comment
Мне нужно 2 файла EDMX для 2 разных схем (в одной базе данных), поэтому я думаю, что теперь я назову их так: Schema1DbModel.edmx, Schema1DbContext и то же самое для Schema2. Ты бы согласился с этим? Я предполагаю, что это больше подошло бы нашим разработчикам, потому что все очень хорошо знают схемы, и для нас это было бы понятно. - person timmkrause; 26.03.2012
comment
Или вы бы вырезали Db в DbModel для файлов EDMX? Вместо этого ничего не используйте или используйте EfModel, как сказал knoia? - person timmkrause; 26.03.2012
comment
Что бы вам ни подходило, EfModel может быть хорошим вариантом, лично мне нравятся имена, не зависящие от реализации. Но что бы вы ни выбрали: будьте последовательны! - person Gert Arnold; 26.03.2012
comment
Последний вопрос: что вы имеете в виду под независимостью от реализации? Итак, вы бы просто выбрали модель (например, Schema1Model)? - person timmkrause; 26.03.2012
comment
Я имею в виду, не имея в виду, например. каркас сущности. Завтра вы можете выбрать linq to sql (ну, маловероятно, но вы поняли). - person Gert Arnold; 26.03.2012

Мое предложение состояло бы в том, чтобы использовать что-то, что указывает на содержимое в именовании. Например, вы можете взять часть имени вашего проекта и преобразовать его в имя EDMX. Включите что-то, что сделает его менее общим.

Я также склонен включать «Ef» в свое имя, которое я начал, когда работал над проектом, в котором уже была существующая ORM.

Возьмем типичный пример Microsoft: если ваш проект подпадает под общее имя Norwind, вот как я назову некоторые файлы в моем типовом проекте:

Файл EDMX: NorwindEfModel.edmx

Файл генератора/TT: NorwindEfDbContext.tt

Класс сущностей: NorwindEntities

Я не могу сказать, что Microsoft сделала бы это именно так, если бы вы скачали у них пример проекта (хотя я полагаю, что это было бы похоже), но я думаю, что это разумная структура именования, и она соответствует моим потребностям. Суть в том, что это в значительной степени сводится к мнению и вашей потребности в конкретном различии.

person knoia    schedule 25.03.2012