Как работать с крупными объектами?

У меня есть 5 типов объектов: информация о месте (14 свойств), информация о компании-владельце (5 свойств), изображение, рейтинги (хранит несколько результатов голосования), комментарии.

Все эти 5 объектов соберутся в один объект (место), который будет иметь все свойства и информацию обо всей информации о месте, изображениях, комментариях и т. д.

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

Я практиковался какое-то время, но так и не получил опыта реализации и производительности, но я чувствовал, что это уже слишком!

Что вы думаете?


c# asp.net performance webforms business-objects
person Mazen Elkashef    schedule 06.03.2011    source источник
comment
Что именно вы здесь просите? Мнения?   -  person Oded    schedule 06.03.2011
comment
Yh, я хочу знать, большие ли такие объекты? .. неисправен ли мой дизайн и как с этим бороться!   -  person Mazen Elkashef    schedule 06.03.2011
comment
14 свойств в объекте — это не проблема. В некоторых сложных сценариях вы найдете намного больше, чем это.   -  person Pradeep    schedule 06.03.2011
comment
Хорошо, представьте, что объект комментариев имеет текст из 500 символов, а у вас около 50 комментариев, это всего лишь один объект из 5 объектов, которые будут составлять информацию о месте ... более того, если бы я загрузил около 9 из них в список в объект профиля владельца .. как вы думаете, все еще в порядке !?   -  person Mazen Elkashef    schedule 06.03.2011

Ответы (2)


arrow_upward
3
arrow_downward

Вы должны изучить сценарии использования вашего решения. Вам нужно всегда показывать все данные или вы начинаете с отображения только их части? Могут ли пользователи разворачивать какие-либо свернутые элементы в рамках регулярного использования или эта информация используется только в менее распространенных случаях?

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

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

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

person Morten Mertner    schedule 06.03.2011
comment
Я могу разделить пользовательский интерфейс, чтобы отображать информацию о каждом объекте на отдельной вкладке... но мои DAL и BLL заполняют объект полной информацией (все его объекты)... какой дизайн я могу использовать для получения только необходимых данных? должен загружать каждый объект сам по себе, когда это необходимо? .. NB, хотя я могу разбить информацию на вкладки, мне понадобится быстрый доступ ко всем другим объектам, поскольку все они, вероятно, будут просматриваться (не одинаково, но, скорее всего) - person Mazen Elkashef; 06.03.2011
comment
@IKashef Отредактировал ответ, чтобы включить некоторые рекомендации по доступу к данным. - person Morten Mertner; 06.03.2011
comment
@IKashef Похоже, вы собираетесь использовать объекты домена (также известные как объекты) непосредственно в своих представлениях. Это вообще плохая идея. Используйте специальные настраиваемые классы моделей представлений, чтобы хранить только необходимую информацию, например PlaceViewModel, только со свойствами объекта Place, необходимыми для отрисовки пользовательского интерфейса. Здесь вы можете найти множество вопросов/ответов, связанных с MVC, и ознакомиться с соображениями по проектированию модели. - person Morten Mertner; 06.03.2011
comment
@lKashef Если производительность становится проблемой, вы можете использовать разные стратегии выборки для разных вариантов использования вашего объекта Place, каждая из которых загружает только необходимые данные. И вы можете положиться на старый трюк, называемый кэшированием. - person driushkin; 06.03.2011
comment
@дрюшкин. Спасибо, я пойду своим путем до конца, и если у меня возникнут какие-либо проблемы, я попытаюсь изучить тестирование производительности и кэширование. Надеюсь, это путь! - person Mazen Elkashef; 06.03.2011
comment
@ Мортен Мертнер. Я не заметил твоего редактирования, я прочитаю его и отвечу, но @твой другой комментарий, Yh! Я использую сущности для каждой таблицы в моей базе данных и позволяю моему DAL извлекать их и помещать в объект/сущность, а BLL проверяет объект и отправляет его в List‹Entity›, если их больше одного, иначе Я просто отправляю объект (скажем, объект места) в пользовательский интерфейс. Ваш совет Использовать специальные классы модели представления, адаптированные для меня, не совсем понятно для меня, потому что я мало узнал о других шаблонах, и это звучит как хорошая идея но сложно ли реализовать это с помощью веб-форм? - person Mazen Elkashef; 06.03.2011
comment
@ Мортен Мертнер. Итак (лучше получить все данные о месте и включить все, что нужно странице), а не (извлекать начальную сумму, чтобы запустить первую страницу, а затем при необходимости извлекать необходимые данные для каждой вкладки?) .. если вы можете проверьте этот дополнительный вопрос, касающийся моей техники доступа к данным, это было бы здорово stackoverflow.com/questions/5213171/ ..+1 - person Mazen Elkashef; 06.03.2011

arrow_upward
1
arrow_downward

На самом деле у вас есть 3 проблемы, и они часто делятся на DAL, BLL и UI.

Ваши объекты, очевидно, принадлежат BLL, и если вы рассматриваете производительность, вам необходимо подумать о том, как ваши объекты будут создаваться и как они взаимодействуют с DAL. У меня много объектов с 50-200 свойствами, поэтому 14 свойств не проблема.

Сторона пользовательского интерфейса является отдельной, и если вы рассматриваете производительность отображения большого количества информации на одной странице, вы рассмотрите содержимое с вкладками, сетки и т. д.

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

person cusimar9    schedule 06.03.2011
comment
Я не понял, что вы хотите сказать о части DAL ... но я боюсь, что их будет много для загрузки на страницу сразу, поэтому я подумал о содержимом с вкладками, как вы предложили, но я не знаю, как я реализую это в своем BLL (примечание: у меня есть слой бизнес-объектов и слой бизнес-логики) - person Mazen Elkashef; 06.03.2011
comment
DAL — это уровень доступа к данным, то есть ваши SQL-запросы или хранимые процедуры. Если вы думаете о том, как вы будете отображать данные в пользовательском интерфейсе, вам доступно несколько вариантов, и все они зависят от того, как вы хотите отображать данные. Взгляните на объекты Telerik, они очень полезны. - person cusimar9; 06.03.2011
comment
Извините, если я неясно выразился, я знаю, что такое DAL, но я не понимаю, что вы имели в виду, говоря о том, как будут создаваться ваши объекты и как они взаимодействуют с DAL... хм, так какие у меня варианты? пожалуйста, проверьте мой комментарий к ответу Мортена Мертнера, и если вам нужно узнать что-то еще, пожалуйста, дайте мне знать! =) Спасибо кузимар - person Mazen Elkashef; 06.03.2011