Я пытаюсь найти самый чистый способ сделать это.
В настоящее время у меня есть объект клиента:
public class Customer
{
public int Id {get;set;}
public string name {get;set;}
public List<Email> emailCollection {get;set}
public Customer(int id)
{
this.emailCollection = getEmails(id);
}
}
Тогда мой объект электронной почты тоже довольно простой.
public class Email
{
private int index;
public string emailAddress{get;set;}
public int emailType{get;set;}
public Email(...){...}
public static List<Email> getEmails(int id)
{
return DataAccessLayer.getCustomerEmailsByID(id);
}
}
DataAccessLayer в настоящее время подключается к базе данных и использует SqlDataReader для итерации по набору результатов, создает новые объекты электронной почты и добавляет их в список, который он возвращает по завершении.
Так где и как я могу улучшить это?
Должен ли мой DataAccessLayer вместо этого возвращать DataTable и оставлять его до объекта Email для анализа и возврата списка обратно клиенту?
Я полагаю, что "Фабрика", возможно, неправильное слово, но должен ли я иметь другой тип EmailFactory, который берет DataTable из DataAccessLayer и возвращает List в объект Email? Я думаю, что такие звуки излишни ...
Это даже правильная практика, когда мой Email.getEmails (id) используется как статический метод?
Я мог бы просто скинуть себя, пытаясь найти и применить лучший «шаблон» к тому, что обычно было бы простым заданием.
Спасибо.
Последующие действия
Я создал рабочий пример, в котором мой объект Domain / Business извлекает запись клиента по идентификатору из существующей базы данных. Файлы отображения xml в nhibernate действительно аккуратны. После того, как я последовал руководству по настройке фабрик сессий и хранилищ, извлечение записей из базы данных было довольно простым.
Однако я заметил огромный удар по производительности.
Мой оригинальный метод состоял из хранимой процедуры в БД, которая была вызвана объектом DAL, который проанализировал набор результатов в моем домене / бизнес-объекте.
Я использовал свой первоначальный метод - 30 мс, чтобы получить одну запись клиента. Затем я выбрал метод nhibernate, взяв 3000 мсек для получения той же записи.
Я что-то упустил? Или этот маршрут nhibernate просто перегружен?
В противном случае мне нравится чистота кода:
protected void Page_Load(object sender, EventArgs e)
{
ICustomerRepository repository = new CustomerRepository();
Customer customer = repository.GetById(id);
}
public class CustomerRepository : ICustomerRepository
{
public Customer GetById(string Id)
{
using (ISession session = NHibernateHelper.OpenSession())
{
Customer customer = session
.CreateCriteria(typeof(Customer))
.Add(Restrictions.Eq("ID", Id))
.UniqueResult<Customer>();
return customer;
}
}
}
Пример , которому я следовал , заставил меня создать вспомогательный класс, чтобы помочь управлять сессией, может быть, поэтому я получаю такие накладные расходы?
public class NHibernateHelper
{
private static ISessionFactory _sessionFactory;
private static ISessionFactory SessionFactory
{
get
{
if (_sessionFactory == null)
{
Configuration cfg = new Configuration();
cfg.Configure();
cfg.AddAssembly(typeof(Customer).Assembly);
_sessionFactory = cfg.BuildSessionFactory();
}
return _sessionFactory;
}
}
public static ISession OpenSession()
{
return SessionFactory.OpenSession();
}
}
С приложением, над которым я работаю, скорость имеет значение. И, в конечном счете, много данных будет передаваться между веб-приложением и базой данных. Если агенту понадобится 1/3 секунды, чтобы восстановить запись о клиенте, а не 3 секунды, это будет большим успехом. Но если я делаю что-то странное, и это однократная первоначальная стоимость установки, то это может стоить того, чтобы производительность была такой же хорошей, как и выполнение хранимых процедур в БД.
Все еще открыты для предложений!
Обновлен.
Я отменяю свой маршрут ORM / NHibernate. Я обнаружил, что производительность слишком медленная, чтобы оправдать ее использование. Основные запросы клиентов просто слишком долго для нашей среды. 3 секунды по сравнению с ответами менее секунды слишком много.
Если бы мы хотели медленные запросы, мы бы просто сохранили нашу текущую реализацию. Идея переписать его состояла в том, чтобы резко увеличить время.
Однако, после игры с NHibernate на прошлой неделе, это отличный инструмент! Это просто не совсем соответствует моим потребностям в этом проекте.