У меня есть веб-приложение .net, которое я перенял, которое в прошлом страдало от того, что вся бизнес-логика была в коде позади страниц и очень сильно привязана к интерфейсу пользователя.
Я потратил некоторое время на рефакторинг, в частности на перенос кода доступа к данным в выделенный проект доступа к данным «Company.DataAccess» (например). Другие логические части кода также имеют свои собственные сборки.
Что меня не устраивает, так это размещение объектов, которые необходимо разделить между сборками:
Например, в моем проекте "Company.ClientDataImport" у меня есть классы, содержащие бизнес-логику для импорта данных клиента.
Одна особенность функциональности, которая включает этот код, заключается в том, что формат импорта клиента может быть сопоставлен с нашим форматом импорта по умолчанию. Итак, у меня есть класс «DataImportFieldMappingInfo» в сборке «Company.ClientDataImport»:
public class DataImportFieldMappingInfo {
int CompanyFieldName
{
get;
set;
}
int ClientFieldName
{
get;
set;
}
}
Эти отображения хранятся в базе данных, поэтому в какой-то момент мне нужно заполнить коллекцию экземплярами этого объекта.
Одной из целей архитектуры является то, что все операции ввода-вывода базы данных должны обрабатываться "Company.DataAccess".
Я хочу, чтобы «Company.DataAccess» знал о классе DataImportFieldMappingInfo, чтобы он мог использовать класс так, как это было предназначено для хранения данных этого типа, но это означает, что «Company.DataAccess» и «Company.ClientDataImport» оба необходимо знать о DataImportFieldMappingInfo, чтобы они могли общаться с использованием одних и тех же классов.
Мое решение этой распространенной проблемы до сих пор заключается в использовании другой библиотеки под названием «Company.DomainEntities», которая содержит классы для объектов, которые совместно используются другими сборками в приложении. Это работает хорошо, и все сборки могут взаимодействовать в рамках одних и тех же объектов. Классы на самом деле просто содержат свойства, поэтому они являются просто контейнерами данных, а не логикой приложения.
Что мне не нравится в этом, так это то, что DataImportFieldMappingInfo представляет собой проблему импорта данных, и поэтому я считаю, что она должна находиться в этом пространстве имен и, следовательно, в проекте «Company.ClientDataImport». Однако ограничения круговой ссылки препятствуют этому, поэтому я должен использовать проект Company.DomainEntities в качестве посредника.
Что-то не так с моей архитектурой, или это обычная практика в такой ситуации?