Огромный объект в веб-приложении

Question

Я пишу веб-приложение, и у меня огромный класс, в котором более 40 членов, 3 типа массивов и много методов.Этот класс представляет задачу со всеми ингредиентами задачи, включая цену задачи.Проблема в том, что мне нужно передать клиенту список из 40 первых заданий, поэтому я передаю 40 полных заданий, которые становятся очень большими и весят много КБ.Как я могу уменьшить этот объект ?? ..

Вот изображение диаграммы класса: http://www.imagehousing.com/image/624350

Answer 1

Первое, что я хотел бы решить, прежде чем даже думать о отправке чего-либо, это то, что вы реорганизуете этот класс в более управляемые подкомпоненты.Возьмем, к примеру, свойства типа DeliveryNote, DeliveryNoteId, DeliveryNoteSerial, которые могут быть размещены в классе Delivery.То же самое можно сказать о Group, Payback и других аналогично названных свойствах.При разработке свойств класса вам нужно спросить себя, являются ли эти свойства специфичными для родительской модели или специфичными для меньшей проблемной области.

После того, как вы произвели рефакторинг этого класса, вам необходимо определить какие данные нужны клиенту.Нужна ли им каждая статья данных в этом классе.Если нет, то почему бы не создать класс представления, основанный на потребностях клиента, и отправить только это.

Если вы не считаете, что частичное представление подходит для ваших данных, вы можете использовать DataContractAttribute и DataMemberAttribute атрибуты для управления тем, какие части вашей модели фактически представляют контракт данных, передаваемый клиенту.Например:

[DataContract]
public class Task
{
  [DataMember]
  public string PropertyA { get; set; }

  [DataMember]
  public string PropertyB { get; set; }

  public string PropertyC { get; set; }
}

В приведенном выше примере, используя эти атрибуты, я могу обеспечить, чтобы PropertyA и PropertyB составляли составные части контракта данных.PropertyC не будет частью контракта, поэтому не будет сериализован.Это, конечно, зависит от использования DataContractSerializer или службы WCF (которая использует этот сериализатор).

Это также ограничивает представление контракта с единичными данными модели.

Answer 2

Я думаю, что вы должны следовать какому-то основному правилу.Наличие большого класса создает проблему, чтобы понять код и поддерживать его.

1. Перечислите все существительные и глаголы
2. Сгруппируйте общие существительные и связанные глаголы и создайте класс
3. Повторяйте ту же процедуру, пока не останется существительное и глаголы.
4. Теперь вы должны серьезно задуматься над созданными классами и их методами a.Общие и специализированные классы поиска б.Если есть необходимость в шаблоне проектирования, подумайте и создайте такие отношения, как Обобщение и Специализация, Ассоциация, Зависимость и реализация

Вышеуказанный шаг автоматически придаст более высокую форму классу.

Answer 3

На первый взгляд, я думаю, что вам нужно уменьшить / упростить ваш класс, чтобы 40 членов не были действительно непосредственными членами, например:

Discount, DiscountTypeCode, DiscountTypeId, DiscountTypeSign могут все стать классом ->

class Discount {
    float rate;
    int typeCode, typeId;
    string sign;
}

Простая группировка каждого члена с одинаковым префиксом для класса. Это нужно не только для обрезки по размеру, но и лучшего обслуживания. Чтобы уменьшить размер, вам решать, нужно ли включать эти подчиненные объекты для отправки клиенту, поскольку это веб-приложение, я не думаю, что каждый раз, когда вашему клиенту нужно все в объекте, поэтому, пока вы возвращаете свой объект, подумайте верните только часть этого, создайте это в другой модели представления.