Является ли объявление объекта бизнес-уровня публичным свойством на главной странице asp.net хорошим ходом?
В настоящее время я работаю в приложении ASP.Net C# и использую шаблон проектирования DAL с наборами данных и бизнес-уровнями.
Обычно, когда я запрашиваю данные в своем коде C#, я создаю объект бизнес-уровня:
BLLAccount oblAccount = new BLLAccount();
тогда я могу работать с ним, вызывая функции, которые я объявил в BLLAccount: oblAccount.GetAccounts();
эта процедура повторяется на каждой странице и при каждом запросе данных в каждой области события. Вы можете понять, что это быстро раздражает, поэтому я объявил свойство страницы, поэтому мне не нужно каждый раз воссоздавать один и тот же объект:
private BLLAccount m_BLLAccount = null;
public BLLAccount oblAccount
{
get
{
if (m_BLLAccount == null)
{
m_BLLAccount = new BLLAccount();
}
return m_BLLAccount;
}
}
таким образом, объект создается только в тот момент, когда он мне нужен, и может быть повторно использован в любой области событий. это полезно на странице, но сейчас я создаю много страниц, и даже это решение становится раздражающим. первое, о чем я подумал, это то, что в настоящее время я использую мастер-страницы и дочерние страницы, так почему бы не поместить свойство страницы на мастер-страницу, сослаться на мастер-страницу в моем aspx с помощью этого небольшого фрагмента?
<%@ MasterType VirtualPath="~/Master.master" %>
и в моем коде сослаться на это следующим образом:
Master.oblAccount.GetAccounts();
это работает круто и действительно хорошо, но я не уверен, какое влияние это оказывает на память сервера и производительность приложения. Будет ли очищено свойство моей страницы, если оно не используется слишком долго или нет? начальная нагрузка будет слишком большой? лучше создать конструктор на самом бизнес-уровне или это не имеет большого значения?
1 ответ
Помещение в MasterPage кажется излишним. Как насчет создания класса, который наследует от Page
и все ваши страницы, которым нужен доступ к слою данных, наследуются от этого класса.