n-слойная архитектура - BLL, DAL и интерфейсы. Что такое лучшая практика?

Question

У меня вопрос по n-слойной архитектуре.Я долго и усердно размышлял, прежде чем задавать этот вопрос, так как здесь уже есть много похожих вопросов ... однако, буквально через полтора дня, глядя на него и прочитав эти ответы, я все еще не уверен.Разнообразие, казалось бы, схожей терминологии и разных подходов сбило меня с толку.

Если бы у меня были BLL и DAL в разных библиотеках классов, одним из способов взаимодействия между BLL и DAL было бы использование интерфейса, своего родакак DTO, определенный в другой отдельной DLL, на которую ссылаются как BLL, так и DAL.Объекты модели моего домена в BLL будут реализовывать этот интерфейс, как и любые объекты, созданные ORM в DAL.Чтобы сохранить свои бизнес-объекты, я мог бы затем передать их в DAL, который бы хорошо их принял, поскольку они реализуют общий интерфейс.Я также мог бы передавать объекты обратно в BLL, которые реализуют этот интерфейс.Это кажется разумным, поскольку и BLL, и DAL должны знать только базовый интерфейс, а не конкретную реализацию друг друга.

Мой вопрос: каков наилучший способ создания объекта на другой стороне?Например, если у меня есть объект Person в BLL, который реализует IPerson, и PersonDataObject или что-то еще в DLL, которая также реализует IPerson, я передаю Person в метод в DAL, который принимает параметр IPerson, затем в DAL I 'Я должен восстановить PersonDataObject, чтобы сохранить.Это даже самый лучший метод?

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

Answer 1

Вообще говоря, объекты в BLL будут использовать интерфейсы, а не реализовывать их:

Например, если у меня был объект Person в BLL, который реализовал IPerson, и PersonDataObject или что-то в DLL, которая также реализует IPerson

Взяв в качестве примера «человека»: подумайте о различных операциях с данными, связанными с человеком (получение всех данных для одного человека, сбор поверхностных данных для многих людей, операции CRUD, поиск и т. Д.) - затем разрабатывать интерфейсы вдоль логических группировок (см. Принцип разделения интерфейсов ).

Интерфейсы могут представлять операции с точки зрения BL - или с точки зрения «службы».

Во всяком случае, чтобы ответить на ваш конкретный вопрос ...

Я определяю свой эквивалент DTO в Общей сборке, а также Интерфейс данных в отдельной - поэтому у меня есть 4 сборки: BL, Определение интерфейса доступа к данным, Реализация интерфейса и Общая; все сборки ссылаются на общую.

Я работаю в C # .Net, я определяю DTO как структуры (но вы можете использовать классы); и все их свойства доступны только для чтения - вы вводите данные в них в конструкторе - таким образом DTO являются «тупыми» оболочками информации.

Answer 2

Следуя n-уровневой архитектуре, очень распространено разделение объектов данных между BL и DAL. Иногда один и тот же объект данных может использоваться и на уровне пользовательского интерфейса.

Обычно у меня есть сборка модели данных (или объектов данных или модели предметной области, как бы вы ее ни называли), в которой все объекты модели размещаются как интерфейсы. На примере ваших людей я создам интерфейс IPeople в сборке модели. DAL вернет экземпляр IPeople BL. BL использует этот экземпляр и при необходимости передает его на уровень пользовательского интерфейса после применения бизнес-логики.

Answer 3

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