Дизайн DAL / DataSet / Бизнес-объекты - PullRequest
1 голос
/ 24 сентября 2011

В настоящее время я разрабатываю приложение (.Net WinForms), которому требуется доступ к базе данных (SQL Server).

Используя мастер источников данных, Visual Studio автоматически создает набор данных, таблицы и классы для строк:

Например, если у меня есть таблица «Клиенты», мастер создаст класс «CustomersRow», который наследуется от Global.System.Data.DataRow с соответствующими полями в качестве свойств.

В моем приложении мне нужнореализовать другие методы и атрибуты для класса Customers.

Как работать с этими сгенерированными классами, изменять их, добавляя методы ... или игнорировать их и реализовывать свои собственные бизнес-классы?

Второй вопрос:

Как заполнить мои объекты (например, список клиентов?)

Вы предлагаете использовать datatables / dataset и их методы или создать свой собственный уровень доступа к данным, и я встречаю список клиентов (изклиенты)?

При поиске в сети я обнаружил некоторые закономерности, но они не точные.

Спасибо

Ответы [ 4 ]

1 голос
/ 24 сентября 2011

Я бы сказал, что шаблон проектирования целиком и полностью зависит от масштаба проекта и того, каким "будущим" вы хотите его видеть.Сколько пользователей будет использовать программное обеспечение?Являются ли данные доступными для многих одновременно работающих пользователей?Насколько «актуальными» должны быть данные, когда к ним обращается пользователь?

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

Независимо от масштаба полезно создать как минимум следующие отдельные слои:

DAL -ответственныйисключительно для обновления и извлечения данных

бизнес-логика - набор объектов и методов, представляющих программное обеспечение процесса, за которое отвечает (только бизнес-логика имеет доступ к DAL)

UI - служит для представления данных пользователю и получения ввода от пользователя на основе бизнес-логики (пользовательский интерфейс ссылается на уровень BL и только по своим правилам может получать доступ к данным и изменять их)

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

0 голосов
/ 24 сентября 2011

посмотрите на мой другой ответ здесь:

MVC3 и Entity Framework

в основном MVC, WinForms, WPF или все, что у вас есть в качестве слоя представления, уровень, который я описал, все еще действует.

реальная форма вашего уровня доступа к данным может измениться внутренне в зависимости от того, что вы используете там, например, NHibernate, Entity Framework, вообще никакого ORM, кроме доступа к чистому / чистому SQL, все, что вы делаете, ограничено и содержится в нем, будет иметь большую жизнь, если вы максимально абстрагируетесь от нее, а все остальные слои будут созданы независимо от нее.

0 голосов
/ 24 сентября 2011

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

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

Хорошо иметь хотя бы один слой между вашей настойчивостью и клиентом. Это дает вам гибкость в размещении домена и / или службы между клиентом и базой данных. Я бы не пошел дальше этого, если бы вы не решили конкретную проблему.

Что касается загрузки из вашей персистентности, вы можете использовать частичные классы для расширения сгенерированных классов персистентности. Это простой способ добавить дополнительную функциональность, сохраняя оригинальные свойства и методы в такте.

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

using MyApp.Domain;

public class Customer
{
    public string Name { get; set; }
    public string Address { get; set; }
    public int ID { get; set; }

    public static MyApp.Domain.Customer Create( MyApp.Persistence.Customer pcustomer )
    {
        return new MyApp.Domain.Customer
        {
            Name = pcustomer.Name,
            Address = pcustomer.Address,
            ID = pcustomer.ID
        }
    }

    public void Persist( MyApp.Persistence.Customer pcustomer )
    {
         pcustomer.ID = this.ID;
         pcustomer.Name = this.Name;
         pcustomer.Address = this.Address;
    }

}

Вот как может выглядеть частичный класс. Ключ в том, чтобы пространство имен класса совпадало с пространством имен вашего сгенерированного типа персистентности.

using MyApp.Persistence;

public partial class Customer
{
     public string FormatedAddress
     {
         // I now have access to all the generated members because
         // I'm extending the definition of the generated class
         get
         {
             return string.Format( "{0}\n{1},{2} {3}",
                                   StreetAddress,
                                   City, 
                                   State,
                                   ZipCode );
         }
     }

}
0 голосов
/ 24 сентября 2011

Я тоже новичок в шаблонах проектирования, но думаю, что лучшим решением было бы поместить бизнес-слой поверх ваших сгенерированных классов и DAL.Затем в этом слое вы могли бы реализовать свои собственные методы и атрибуты для ваших классов, возможно, вам следует рассмотреть возможность использования для этого объектов POCO.

...