ORM и POCO при наличии нескольких Backends / DI - Архитектура? AutoMapper?

Question

Хорошо, название не говорит слишком много, извините. По сути, это вопрос архитектуры о приложении, которое может иметь несколько серверных баз данных (ну, здесь «база данных» используется свободно, так как оно может означать что угодно, от MSSQL до файлов XML и IList в памяти), в основном с использованием шаблона репозитория.

У меня есть набор POCO, которые по сути просто служат объектом передачи данных (DTO) и поэтому ничего не делают, кроме переноса данных. К сожалению, я вижу необходимость в украшении их Атрибутами, т.е. для использования с определенными ORM или даже для использования с XmlSerializer. Это означает, что они теперь в некоторой степени связаны с уровнем базы данных и, на мой взгляд, больше не являются простыми POCO.

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

Это все еще "кажется странным", так как я по сути дублирую все свои классы DTO, но существование картографов Object-to-Object, кажется, указывает на то, что это совершенно нормально. Кроме того, похоже, что это копирует подход ADO.net, в то время как есть общая часть (вплоть до набора данных) и специфичная для базы данных часть.

Это правильно? Или есть другой подход?

Answer 1

В (несколько ограниченном) случае только , требующих добавления атрибутов для использования с заданным ORM, можно написать оболочку, которая добавляет эти вещи во время выполнения. Вы можете добавить такой код в конструктор ORM (при необходимости подклассифицировать класс инициализации ORM или ORM) или в событие инициализации ORM.

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

 PropertyDescriptor[] properties = TypeDescriptor.GetProperties(this);
 //Add as necessary
 string[] propertiesToTagForORM = { "Name", "Category", "Description" };

 foreach (string propname in propertiesToTagForORM)
        {
            PropertyDescriptor prop = properties[propname];
            if (prop != null)
            {
                AttributeCollection runtimeAttributes = prop.Attributes;
                // make a copy of the original attributes 
                // but make room for one extra attribute
                Attribute[] attrs = new Attribute[runtimeAttributes.Count + 1];
                runtimeAttributes.CopyTo(attrs, 0);
                attrs[runtimeAttributes.Count] = new BrowsableAttribute(false); 

                prop = TypeDescriptor.CreateProperty(this.GetType(), propname, prop.PropertyType, attrs);
                properties[propname] = prop;
            }
        }
}

Адаптировано с здесь . Просто идея - это, пожалуй, первое направление, в котором я буду двигаться:)

Answer 2

Вы должны спросить себя, что происходит не так, когда вы включаете эти атрибуты в свои POCO. Особенно, если ваши POCO не делают ничего, кроме переноса данных и не служат в качестве модели предметной области с бизнес-логикой, которую вы бы хотели сохранить в атрибутах отдельной формой «технические детали». В этом случае единственным недостатком этих атрибутов кажется небольшая утечка технических деталей более низких уровней к более высоким уровням. Но оправдывает ли это совершенно новый слой, в котором вы делаете не что иное, как «глупое копирование атрибутов». Я бы наверное сказал нет.

Короче говоря: всегда тщательно продумайте, не является ли решение воспринимаемой проблемы самой другой (и, возможно, даже более крупной) проблемой. Я сам не стал бы сильно беспокоиться об этих атрибутах в случае, который вы иллюстрировали. Во всяком случае, я бы предпочел поискать варианты, чтобы атрибуты не попадали в POCO и помещали их в другие ресурсы (классы или файлы конфигурации), чем для введения дополнительного уровня преобразования.