Лучший "шаблон" для уровня доступа к данным для бизнес-объекта

Я пытаюсь выяснить самый чистый способ сделать это.

В настоящее время у меня есть объект клиента:

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 для анализа и возврата списка обратно клиенту?

Я думаю, что "Factory", вероятно, является неправильным словом, но должен ли я иметь другой тип EmailFactory, который берет DataTable из DataAccessLayer и возвращает объект List to 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 на прошлой неделе, это отличный инструмент! Это просто не совсем соответствует моим потребностям в этом проекте.