Лучшие практики использования наборов типизированных данных C # XSD в корпоративных приложениях - PullRequest
6 голосов
/ 20 января 2010

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

1) Считаете ли вы, что информация XSD должна находиться как часть модели?

2) Означает ли это, что уровень доступа к данным возвращает наборы данных и другие сгенерированные объекты?

3) Проходит ли он все системные уровни вплоть до пользовательского интерфейса?

4) Если XSD является частью уровня доступа к данным, следует ли преобразовывать результаты в объекты из модели? Какая методология конвертации лучше?

Спасибо, Ronny

1 Ответ

7 голосов
/ 20 января 2010

Вы ограничили назначение и применение XSD, сделав XSD специфичными для наборов данных в вашем вопросе.

XSD является аббревиатурой от Расширяемого определения скемы. Стандарты XSD определены W3C ради стандартизации XML-файлы, которые вы можете использовать в своем приложения.

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

Теперь отвечаю на ваши вопросы ..

1.) Считаете ли вы, что информация XSD должна располагаться как часть модели?

Как я только что сказал, XSD-файл хранит схему, а не данные. То же самое в любом приложении, когда вы используете наборы данных, которые фактически хранят данные в памяти во время выполнения, - также будет иметь свою собственную схему, форму, в которой они будут хранить данные. Они различаются в зависимости от базовых таблиц данных и их отношений. Итак, ребята из MS представили концепцию TypedDataSets. TypedDataSets - как следует из названия, это квалифицированная схема набора данных, которую вы собираетесь использовать во время выполнения для воспроизведения данных. Таким образом, TypedDataSets фактически определены в форме файла XSD, который определяет схему DataTables и отношения между ними. Поэтому, когда вы создаете файл TypedDataSet в Visual studio, он в основном создает файл XSD. Все таблицы, которые вы добавляете из источника базы данных на поверхность TypedDataSet, будут проанализированы, а схема метаданных каждой таблицы будет создана в файле XSD. Во время выполнения, когда вы выбираете записи в свой набор данных, вы уже знаете, какие данные поступают в них, и если данные не в форме, как определено в XSD, вы получите исключение времени выполнения.

Тем не менее XSD не являются полезными во время выполнения, поскольку Visual Studio генерирует кодовую базу tpyed-dataset из файла XSD с помощью инструмента XSD.exe .

2) Означает ли это, что уровень доступа к данным возвращает наборы данных и другие сгенерированные объекты?

Если ваш слой данных использует TypedDataset, он вернет DataTables или DataRow [] или DataRow, как вам нужно.

3) Проходит ли он все системные слои вплоть до пользовательского интерфейса?

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

4) Если XSD является частью уровня доступа к данным, следует ли преобразовывать результаты в объекты из модели? Какая методология конвертации лучше?

Напишите механизм отображения, используя Reflection. Мы сопоставляем наши экземпляры объекта DataRow с бизнес-объектами и таблицы данных с коллекциями бизнес-объектов.

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

Это то, что у меня есть в моем проекте.

1.) Application.Infrastructure

  • Базовые классы для всех бизнес-объектов, коллекции бизнес-объектов, классы доступа к данным и мои пользовательские атрибуты и утилиты в качестве методов расширения, общая структура проверки. Это определяет общую организацию поведения моего окончательного приложения .net.

2.) Application.DataModel

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

3.) Application.DataAccess

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

4.) Application.DomainObjects

  • Бизнес-объекты и коллекции бизнес-объектов.
  • Перечисления.

5.) Application.BusinessLayer

  • Предоставляет классы менеджера, доступные на уровне презентации.
  • HttpHandlers.
  • Базовый класс моей собственной страницы.
  • Здесь все больше и больше ..

6.) Application.WebClient или Application.WindowsClient

  • Мой уровень презентации
  • Принимает ссылки из Application.BusinessLayer и Application.BusinessObjects.

Application.BusinessObjects используются во всем приложении и перемещаются по всем уровням, когда это необходимо [кроме Application.DataModel и Application.Infrastructure]

Все мои запросы определяются только Application.DataModel.

Application.DataAccess возвращает или принимает бизнес-объекты как часть любой операции доступа к данным. Бизнес-объекты создаются с помощью атрибутов отражения. Каждый бизнес-объект помечается сопоставлением атрибутов с целевой таблицей в базе данных, а свойства внутри бизнес-объекта помечаются сопоставлением атрибутов с целевым столбцом в соответствующей таблице базы данных.

Моя структура проверки позволяет мне проверять каждое поле с помощью назначенного атрибута ValidationAttribute.

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

Пример бизнес-объекта будет выглядеть в моем приложении следующим образом.

User.cs

[TableMapping("Users")]
public class User : EntityBase
{
    #region Constructor(s)
    public AppUser()
    {
        BookCollection = new BookCollection();
    }
    #endregion

    #region Properties

    #region Default Properties - Direct Field Mapping using DataFieldMappingAttribute

    private System.Int32 _UserId;

    private System.String _FirstName;
    private System.String _LastName;
    private System.String _UserName;
    private System.Boolean _IsActive;

    [DataFieldMapping("UserID")]
    [DataObjectFieldAttribute(true, true, false)]
    [NotNullOrEmpty(Message = "UserID From Users Table Is Required.")]
    public override int Id
    {
        get
        {
            return _UserId;
        }
        set
        {
            _UserId = value;
        }
    }

    [DataFieldMapping("UserName")]
    [Searchable]
    [NotNullOrEmpty(Message = "Username Is Required.")]
    public string UserName
    {
        get
        {
            return _UserName;
        }
        set
        {
            _UserName = value;
        }
    }

    [DataFieldMapping("FirstName")]
    [Searchable]
    public string FirstName
    {
        get
        {
            return _FirstName;
        }
        set
        {
            _FirstName = value;
        }
    }

    [DataFieldMapping("LastName")]
    [Searchable]
    public string LastName
    {
        get
        {
            return _LastName;
        }
        set
        {
            _LastName = value;
        }
    }

    [DataFieldMapping("IsActive")]
    public bool IsActive
    {
        get
        {
            return _IsActive;
        }
        set
        {
            _IsActive = value;
        }
    }

    #region One-To-Many Mappings
    public BookCollection Books { get; set; }

    #endregion

    #region Derived Properties
    public string FullName { get { return this.FirstName + " " + this.LastName; } }

    #endregion

    #endregion

    public override bool Validate()
    {
        bool baseValid = base.Validate();
        bool localValid = Books.Validate();
        return baseValid && localValid;
    }
}

BookCollection.cs

/// <summary>
/// The BookCollection class is designed to work with lists of instances of Book.
/// </summary>
public class BookCollection : EntityCollectionBase<Book>
{
    /// <summary>
    /// Initializes a new instance of the BookCollection class.
    /// </summary>
    public BookCollection()
    {
    }

    /// <summary>
    /// Initializes a new instance of the BookCollection class.
    /// </summary>
    public BookCollection (IList<Book> initialList)
        : base(initialList)
    {
    }
}
...