3 уровня приложения - навигационные свойства

Я бы использовал 3 уровня архитектуры в своем веб-проекте. DAL -> EF 4 обтекатель с классическим методом CRUD (AddEntity, RemoveEntity и так далее) BAL -> бизнес-логика и выгрузка запроса (selectByName, byCity, bySomeOtherProperty). UI - Aspx страница3 уровня приложения - навигационные свойства

Моя проблема в навигацииПродукция, открытая EF. Если у меня есть CustomerRepostiory, ASPX стороны я не хочу разрешить операцию лица, которые не являются клиентами, предположив follwing POCO класс:

public class Customer 
{ 
    public int Id {get; set;} 
public string Name {get; set;} 
public ICollection<Orders> Order{get;set;} 
}

и ASPX вы выполнить что-то вроде этого:

var customer = bll.getCustomerByName("alex"); 
customer.Order.Add(new ..) // BAD, I don't want allow it

Что мне делать? Может быть, я должен создать оболочку класса poco, чтобы «скрыть» некоторые свойства? Какой действительно лучший подход?

источник

2012-06-02 bit

Почему вы не хотите, чтобы это? Это потому, что вы хотите ограничить то, что можно сделать на уровне пользовательского интерфейса? Почему это BAD в вашем случае? –

Да, я хочу ограничить то, что можно сделать на уровне пользовательского интерфейса. Кроме того, мой BLL содержит методы Insert, Delete, Update и Save, поэтому они являются единственными, кто отвечает за операции CRUD. Каждая команда нуждается в некоторой проверке, если вы используете navigationProperty для добавления чего-то, я не могу выполнить никаких элементов управления. Вы должны пройти для метода Insert. – bit

Выставляют свою коллекцию как IEnumerable вместо этого, таким образом коллекция будет читать только

Вы должны сделать что-то вроде:

class Customer 
{ 
    private List<Order> orders(); 
    Customer() 
    { 
     this.orders = new List<Order>(); 
    } 

    public IEnumerable<Order> Orders { get { return this.orders.AsEnumerable(); } } 

    // you will need a public method to mutate the collection 

    public void AddOrder(Order order) 
    { 
     // implement custom logic, fire domain events, etc 
     this.orders.Add(order); 
    } 
}

EDIT:

Если вы не можете измените свою сущность (что кажется странным для меня ...), вы можете попробовать использовать ObservableCollection<>

Что-то нечетное как этот

class MyCustomer : Customer 
{ 
    private ObservableCollection<Order> orders; 
    internal bool AllowMutateCollection; 
    public MyCustomer() 
    { 
     this.Orders = this.orders = new ObservableCollection<string>(); 
     this.orders.CollectionChanged += (_, __) => 
     { 
      if(!this.AllowMutateCollection) 
      { 
      throw new NotImplementedException(); 
      } 
     }; 
    } 
}

Теперь вы должны установить AllowMutateCollection, когда позволит мутировать ваш объект, который становится реальной боли и, возможно, это будет причиной некоторых ошибок ... Я не рекомендовать его

Однако я настоятельно рекомендую вам пересмотреть немного ваш дизайн, упаковку вашего класса и разоблачить IEnumerable вместо этого, это было бы чище и легче поддерживать

Проверить этот вопрос

Fire an event when Collection Changed (add or remove)

источник

2012-06-02 19:16:48 Jupaol

Я не хочу, потому что каждый раз, когда мне нужно обновить (переименовать) класс POCO Visual Studio перезапишет мое изменение, и свойство навигации снова станет классом ICollection. – bit

Является ли ваш 'Customer' класс автогенератором? – Jupaol

Да. Клиент автоматически генерируется. – bit

Написать подкласс для Клиента, отменить заказы, сделать геттер делать все права доступа проверки вы хотите

источник

2012-06-02 19:24:33 Filip

3 уровня приложения - навигационные свойства

ответ

Смежные вопросы