Лучшая практика для просмотра данных населения? - PullRequest
1 голос
/ 13 мая 2009

Я работаю над приложением .NET и испытываю ошибку памяти (я Java-разработчик, который может делать другие вещи), я думал о производительности. То, о чем я пишу, не было проблемой с памятью. Проблема памяти только что заставила меня задуматься.

Я повторил тенденцию в своем приложении ASP.NET, которую я использовал в бесчисленных приложениях J2EE: использование бизнес-объектов для заполнения выпадающих списков. Чем больше я об этом думаю, тем больше мне это не нравится. Например, в приложении, над которым я работаю, у нас есть выпадающий список текущих проектов. Проект - это граф объектов. Однако, чтобы создать список, мы возвращаем все проекты, создаем график и используем только идентификатор и отображаемое имя. Это кажется ужасной тратой. Чтобы быть справедливым, слой DAL полностью написан от руки. Ведущий архитектор не допустит ORM, как NHibernate.

Я понимаю, что все эти объекты находятся в GEN0 и быстро собирают мусор. Меня беспокоит то, что я облагаю налогом GC. 5% процессорных ресурсов, необходимых для обработки ГХ, составляют 5% процессорных ресурсов, которые я не могу использовать где-либо еще. Этот сайт - один из немногих, которые я действительно уважаю. Что вы все думаете? Разве плохо для этого использовать модель сущности? Должен ли я создать набор объектов IdValue, которые содержат только отображаемое значение и идентификатор? Будет ли создание такого уровня объекта представления (я не думаю, что это пойдет на бизнес-уровне) просто создать избыточный код?

Спасибо, JPD

Ответы [ 3 ]

1 голос
/ 13 мая 2009

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

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

1 голос
/ 13 мая 2009

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

Хороший DAL, который позволяет вам возвращать только те данные, которые вам нужны, увеличит производительность вашего приложения, а также уменьшит объем памяти, необходимый вашему приложению. Но используете ли вы «слишком много» памяти или нет, я думаю, что в большинстве случаев GC сможет справиться с этим просто отлично.

0 голосов
/ 13 мая 2009

Альтернативный подход заключается в создании легких объектов для ваших целей. В этом случае у вас будет легкий проектный объект только с идентификатором и отображаемым именем. Затем необходимо принять решение о повторном использовании существующего DAL или создании облегченной версии DAL.

...