Comments 9
Первый – это поле Blog_Id станет снова not null. А так же EF будет выполнять валидацию по требованию или перед сохранением в БД, что б убедиться что выполняются все указанные условия.
Не совсем.
Тут описан атрибут
[Required], конфигурация же через Fluent API влияет только на полученную схему БД. Взять следующий код:
Post p = new Post {Title = "blablabla", DateCreated = DateTime.UtcNow, Content = "blablabla"};
context.Posts.Add(p);
Console.WriteLine(context.GetValidationErrors().Count());
context.SaveChanges();
Если свойство Blog помечено как
[Required], то GetValidationErrors() вернет одну ошибку, а SaveChanges() выбросит исключение DbEntityValidationException.Если свойство Blog этим атрибутом не помечено, а используется Fluent API, EF уже не обнаружит никаких ошибок валидации, радостно попробует отправить данные на сервер, а потом вернет
DbUpdateException, внутри которого будет исключение, полученное от сервера.
Логично. Не спорю. В статье в самом начале было указано, что рассматривается только аспект Fluent API., и то не весь. Мне эта статья помогла разобраться с основами Fluent API, что и требовалось. Надеюсь, что другим начинающим тоже поможет. А то, на что Вы указали описывается в туториалах к ASP MVC 4 на оф сайте.
Большое спасибо за статью, пишите продолжение! С постепенным усложнением.
Хм.
Спасибо за статью.
Но я вот до сих пор не знаю, как мне описать табличку ролевой модели mvc, где идет вот так:
class UsersInRoles
public int userid {get; set; }
public int roleid {get; set; }
при условии что оба поля ссылаются на другие таблички (profile, role) и оба не могут быть null
при таком описании данного класса EF и CodeFirst ругаются на отсутствие key.
Спасибо за статью.
Но я вот до сих пор не знаю, как мне описать табличку ролевой модели mvc, где идет вот так:
class UsersInRoles
public int userid {get; set; }
public int roleid {get; set; }
при условии что оба поля ссылаются на другие таблички (profile, role) и оба не могут быть null
при таком описании данного класса EF и CodeFirst ругаются на отсутствие key.
Такие таблицы EF создает сам, в статье это описано как «Определение схемы связующих таблиц и связи многие-ко-многим»
Если каждая пара значений является уникальной, то пометьте эти поля как составной ключ.
если имена полей соответсвуют конвенции, то всё просто:
public class User
{
public int id {get; set; }
public string Name {get; set; }
public ICollection<Role> roles {get; set; }
}
public class Role
{
public int id {get; set; }
public string Name {get; set; }
public ICollection<User> users{get; set; }
}
public class User
{
public int id {get; set; }
public string Name {get; set; }
public ICollection<Role> roles {get; set; }
}
public class Role
{
public int id {get; set; }
public string Name {get; set; }
public ICollection<User> users{get; set; }
}
Нашел еще на русском про EF и CodeFirst ASP.NET MVC 3 в деталях.
Sign up to leave a comment.
Описание связей с помощью Code First Fluent API