Свойства класса, касающиеся запросов List <T>- Дилемма дизайна класса - PullRequest
Новая
       28

Свойства класса, касающиеся запросов List <T>- Дилемма дизайна класса

0 голосов
/ 11 июня 2009

Когда мне нужно получить более одной записи из таблицы (базы данных), мой метод заполняет список определенного класса (все мои методы уровня доступа к данным используют List для операторов выбора на основе набора. Я не использую datatable / dataset или xmlDocument подход). Итак, давайте предположим следующий упрощенный сценарий; У меня есть два класса - клиент и заказ с этими полями / свойствами: 

Class Customer{
   int IDCustomer
   string CustomerName
   string CustomerAddress
   string CustomerCity
}

Class Order{
   int IDOrder
   int IDCustomer
   string SalePersonName
   decimal OrderSubTotal
   datetime OrderDateCreated
}

Итак, допустим, что нам нужен метод, который доставляет в UI (ObjectDataSource) все данные из Свойства класса заказа + CustomerName и CustomerCity из класса Customer. Я хочу, чтобы мой метод из класса Order выглядел так: 

public List<Order> SelectAll(){ 
}

так какой подход я должен использовать для достижения этой цели? Как настроить класс заказа так, чтобы он содержал два дополнительных свойства (CustomerName и CustomerCity), касающихся передового опыта, объектно-ориентированной парадигмы, производительности и т. Д .:

ПОДХОД A: 

Class Order{
   int IDOrder
   int IDCustomer
   string SalePersonName
   decimal OrderSubTotal
   datetime OrderDateCreated
   //--- plus two extra properties of type string
   string CustomerName
   string CustomerCity
}

ПОДХОД B: 

Class Order{
   int IDOrder
   int IDCustomer
   string SalePersonName
   decimal OrderSubTotal
   datetime OrderDateCreated
   //--- plus extra property of type Customer
   Customer _Customer
}

ПОДХОД C:

???

Я нахожусь на .NET 2.0.

Ответы [ 5 ]

1 голос
/ 11 июня 2009

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

0 голосов
/ 11 июня 2009

Поскольку это вопрос проектирования, я думаю, что для полного ответа требуется больше информации, потому что я думаю, что это зависит от обстоятельств.

Если у вас уже есть загруженные объекты Order и объекты Customer и вы используете их для разных целей на уровне представления, тогда создание специализированного класса для выравнивания отображаемых данных является хорошим решением.

Если вы загружаете информацию для отображения списка заказов и нуждаетесь в информации о клиенте по каждому заказу, тогда мне придется спросить, почему вы не просто создаете класс CustomerOrder, в котором есть соответствующие поля, а просто загружаете для начала, потому что вы все равно не собираетесь использовать дополнительные данные Клиента.

Все эти проектные решения зависят от внешних факторов. В конце я бы сказал, что правильное проектное решение, как правило, самое простое, отвечающее вашим потребностям.

0 голосов
/ 11 июня 2009

Если вы разрешите существование отношения один-ко-многим из клиентов к заказу, следует класс клиентов, у которого есть список заказов. Хотя это немного отличается от вашего первоначального запроса, вам, вероятно, будет легче манипулировать клиентом и заказами, которые он содержит, а не дублировать элементы из родительского элемента. 

Class Customer{
   int IDCustomer
   string CustomerName
   string CustomerAddress
   string CustomerCity
   List<Order> orders;

   public List<Order> SelectAll(){ return orders; }
}

Class Order{
   int IDOrder
   //int IDCustomer -not necessary as parent contains this info
   string SalePersonName
   decimal OrderSubTotal
   datetime OrderDateCreated
}
0 голосов
/ 11 июня 2009

Это звучит как работа для ORM .

0 голосов
/ 11 июня 2009

Без вопросов, B. Существует связь один-ко-многим между клиентами и заказами - у клиента много заказов (список заказов), а у заказа есть один клиент (скалярное свойство типа customer). 

public class Customer
{
   public Int32 Id { get; private set; }
   public String Name { get; private set; }
   public String Address { get; private set; }
   public String City { get; private set; }

   public IList<Order> Orders { get { return this.orders; } }
   private readonly IList<Orders> orders = new List<Orders>();
}

Class Order
{
   public Int32 Id { get; private set; }
   public String SalesPersonName { get; private set; }
   public Decimal SubTotal { get; private set; }

   public Customer Customer { get; private set; }
}

Для пользовательского интерфейса вы можете создать отдельный класс, который упаковывает порядок следующим образом. 

public class OrderView
{
    private readonly Order order;

    public OrderView(Order order)
    {
        this.order = order;
    }

    public Decimal SubTotal { get { return this.order.SubTotal; } }
    public String CustomerCity { get { return this.order.Customer.City; } }
    // ...
}
...