Объектные отношения - PullRequest
1 голос
/ 02 июня 2010

Это связано с недавними сообщениями о событиях и управлении памятью в целом. Я задаю новый вопрос, так как не думаю, что программное обеспечение, которое я использую, имеет какое-либо отношение к общей проблеме, и я пытаюсь понять немного больше о том, как правильно управлять вещами. Это ASP.NET.

Я пытался понять потребности в Dispose / Finalize в течение последних нескольких дней и считаю, что достиг стадии, когда я очень доволен, когда я должен / не должен реализовывать Dispose / Finalize , «Если у меня есть члены, которые реализуют IDisposable, я должен явно указывать их вызовы dispose в моем методе dispose». Итак, теперь я думаю, может быть, мое понимание времени жизни объекта и того, что держится за то, что просто неправильно!

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

Итак, у меня есть класс репозитория, в нем у меня есть DataContext, который я создаю при создании репозитория. Я реализую IDisposable, и когда мой вызывающий объект готов, я вызываю Dispose в моем хранилище и явно вызываю DataContext.Dispose (). Теперь один из методов этого класса создает и возвращает список объектов, которые были переданы моему внешнему интерфейсу.

Front End -> Controller -> Repository -> Controller -> Front End.

(Используя Redgate Memory Profiler, я делаю снимок своего программного обеспечения при первой загрузке страницы). Мой интерфейс создает объект контроллера при загрузке страницы, а затем делает запрос в хранилище, отправляя обратно список элементов. Когда страница заканчивается, я вызываю Dispose на контроллере, который, в свою очередь, вызывает dispose в контексте. По моему мнению, это должно означать, что мое соединение закрыто и у меня нет экземпляров моего класса контроллера. Если я затем обновлю страницу, она перейдет к двум «живым» экземплярам класса контроллера. Если я посмотрю на график удержания объектов, то объекты, которые я создал при вызове списка, в конечном итоге будут удерживаться тем, что выглядит как Linq.

Помимо контроллера / хранилища, если я создаю список объектов где-то или я создаю объект и возвращаю его куда-нибудь, могу ли я с уверенностью предположить, что .NET в конечном итоге придет и очистит меня или лучшая практика? «Живые» экземпляры подсказывают мне, что они все еще находятся в памяти и активных объектах, а тот факт, что RMP явно заставляет GC ничего не значить?

Ответы [ 2 ]

1 голос
/ 02 июня 2010

Мой ответ на ваши вопросы состоит из 2 частей:

  1. Как разработчику приложений, вам никогда не придется выполнять GC самостоятельно. Это до .NET. В методе Dispose () вам потребуется только освободить или освободить полученные ресурсы, но не требуется вызывать какой-либо метод для явного сбора мусора. Если вы делаете, в лучшем случае, когда это сделано, является недетерминированным.

  2. Когда ваш контроллер возвращает список к внешнему интерфейсу , помните, что внешнему интерфейсу не нужно ничего знать о том, что является вашей серверной (серверной) технологией. Это может быть C #, Java, PHP, вы поняли идею. Ответ, который серверная часть возвращает внешнему интерфейсу, является просто ответом HTTP и соответствует протоколу HTTP. Поэтому, как только ответ сформирован и возвращен во внешний интерфейс, метод контроллера выходит из области видимости, объекты в этой области используются для сбора мусора. Вам не придется беспокоиться об утечках памяти в этой ситуации.

1 голос
/ 02 июня 2010

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

Другими словами: ваше соединение должно быть закрыто, но в памяти все равно останется «удаленный» экземпляр DataContext.

Возможно, вы захотите прочитать эту статью о сборке мусора .NET.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...