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

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

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

Discount, DiscountTypeCode, DiscountTypeId, DiscountTypeSign может все становится классом ->

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

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

Answer 3

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

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

выше шаг будет автоматическим дать лучшую форму Classe.