Kiedy odsłonić IEnumerable zamiast ICollection?

Question

public class Order 
{ 
public int Id {get;set;} 
[DisplayName("User")] 
public long UserId { get; set; } 
[ForeignKey("UserId")] 
public virtual User User { get; set; } 
public decimal Amount { get; set; } 
} 

Z IEnumurable

public class User 
{ 
public int Id{get;set;} 
public virtual IEnumerable<Order> Orders { get; set; } 
} 

public User GetWithOrders() 
{ 
var myUser=UserRepository.GetByEmail("email@email.com"); 
myUser.Orders=OrderRepository.GetByUserId(myUser.Id); 
return myUser; 
} 

Z ICollection

public class User 
{ 
public int Id{get;set;} 
public virtual ICollection<Order> Orders { get; set; } 
} 

public User GetWithOrders() 
{ 
var myUser=UserRepository.GetByEmail("email@email.com"); 
return myUser; 
} 

nie mam leniwy załadunku przy użyciu IEnumerable dla właściwości nawigacji. Dlatego muszę uzyskać zamówienia dla tego użytkownika z innym zapytaniem.

Mam nawigację z ICollection. Dzięki temu mogę uzyskiwać zamówienia od użytkownika. To wydaje się fajne. Ale potem mogę dodawać nowe zamówienia do użytkownika w kontrolerze bez korzystania z usługi lub repozytorium.

To rodzaj manipulowania danymi na poziomie kontrolera. Czy to anty-wzór?

Answer 1

Ale [z ICollection] Mogę dodać nowe zamówienie w kontrolerze bez korzystania z usługi lub repozytorium.

To znaczy, można to zrobić (zakładając, że nie ma ViewModel dodawania rozkaz użytkownika i SaveChanges() gdzieś):

public class UserController 
{ 
    public ActionResult AddUserOrder(AddUserOrderModel addOrder) 
    { 
     User user = User.GetByEmail(addOrder.UserEmail);   
     user.Orders.Add(addOrder.Order); 
     User.SaveChanges(); 
    } 
} 

A zwłaszcza, że ​​można zrobić user.Orders.Add(...), to jest to efekt uboczny eksponowania typów jednostek z warstwy usługi lub repozytorium.

Jeśli chcesz tego uniknąć, trzeba by zdefiniować i wystawiać obiekt biznesowy zawierający elementy, które chcesz wystawiać:

public class UserBLL 
{ 
    public int Id { get; private set; } 
    public IEnumerable<Order> Orders { get { return _orders.AsEnumerable(); } } 
    private IEnumerable<Order> _orders; 

    public UserBLL(User user) 
    { 
     Id = user.Id; 
     _orders = user.Orders;   
    } 

    public void AddOrder(Order order) 
    { 
     _orders.Add(order); 
    } 
} 

Answer 2

Nie ma tu prawdziwego wyboru. ICollection jest potrzebny EF do kontrolowania niektórych jego aspektów, takich jak wiążące wyniki zapytań i leniwe ładowanie. Używając IEnumerable, zasadniczo wyłączasz tę funkcjonalność, ale wraz z nią zrozumienie przez EF struktury bazowej. Podczas generowania migracji EF nie wygeneruje żadnych wymaganych bazowych tabel łączenia dla relacji M2M, kluczy obcych w powiązanych tabelach itp.

Długie i krótkie, należy użyć ICollection. Chociaż masz rację, to pozwala dodawać elementy, po prostu dodając je do kolekcji w pokrewnym elemencie, sans-DAL, nadal nie mogą być one zapisane, bez dostępu do kontekstu. Jeśli poprawnie skonfigurowałeś DAL, to jest on dostępny tylko przez DAL, więc nadal musisz przekazać go z powrotem do swojego potoku DAL, aby utrwalić którąkolwiek z tych zmian. Innymi słowy, nie przejmuj się tym.