Próbuję zrozumieć całą relację MVC/EF. Jeśli utworzę model encji, który będzie wchodził w interakcje z bazą danych (ponieważ nie powinieneś przekazywać ci modelu encji do widoku), wtedy klasa dla Modelu, a na końcu model widoku pokazany poniżej. Moje jedyne pytanie brzmi: zbędne jest posiadanie drugiej klasy, jedyną różnicą w przykładach, które widziałem, jest to, że stosują adnotacje danych do tej klasy, ponieważ wchodzą w interakcję z widokiem. Dlaczego tak ważne jest upewnienie się, że obiekty encji nie są eksponowane w warstwie widoku?Entity Framework i relacja z MVC
Nie zacząłem jeszcze pisać projektu, ale zakładam, że używałbyś modelu Entity do interakcji z bazą danych, a następnie wrzucisz go do ProductModelu, aby przekazać do widoku, czy to jest właściwa logika?
Entity Model:
public class Product
{
[Key()]
public int ID { get; set; }
public string Name { get; set; }
public string Description { get; set; }
public double Price { get; set; }
}
Model:
public class ProductModel
{
public int ID { get; set; }
[StringLength(50)]
[Required(ErrorMessage = "Product Name is required.")]
[Display(Name = "Product Name")]
public string Name { get; set; }
public string Description { get; set; }
public double Price { get; set; }
}
ViewModel:
public class ProductViewModel
{
Product myProduct { get; set; }\
//Plus any other properties I may need for the view.
}
UPDATE:
W przykład Czytałem, że mają również zestaw DBContext w następujący sposób. Czy więc klasa ProductModel jest bezużyteczna?
public class MyAppContext : DbContext
{
public MyAppContext()
: base("name=DBConnection")
{
}
public DbSet<Product> Products { get; set; }
}
Gdzie można przeczytać, że nie należy zdać „model jednostki” do widzenia? – Floremin