@ResidentEve

У меня программа в общих чертах: есть сущность: класс User. Мы расширяем наше приложение еще одной сущностью - класс Award, т.е. user'ов можем награждать.
Я сделал так:
Создал 4 интерфейса: IUserDAL, IUserLogic, IAwardDAL, IAwardLogic. Интерфейс IUserDAL наследуется от IAwardDAL, IUserLogic от IAwardLogic. В классе логики создаем переменную типа интерфейса IUserDAL и через нее обращаемся к методам нашего DALa.
Вопрос вот в чем: правильно ли это, что нужно одному интерфейсу наследоваться от другого? И сколько в логике по сути должно лежать переменных в данном случае (когда есть две сущности)? Я тут вообще сначала сделал без наследования интерфейсов, просто создал две переменных в логике: userDAL и awardDAL. Но при каждой операции пришлось бы и там и там вносить изменения, т.е. какой-то абсурд. Кто что думает?

1

@Cupko

1. Причем здесь трёхслойная архитектура?
2. За что отвечают DAL и Logic?
3. User и Award - разные сущности, хоть и связанные. User должен работать с User, Award - с Award. Зачем тут что наследовать?

0

@ResidentEve

Задача из учебного центра на понимание трехслойной архитектуры, я учусь только.
DAL - Data Access Layer; Logic - это промежуточный слой между консолью (Presentation Layer) и DAL'om.
Т.е. получается, что нужно делать два DAL отдельно для User и отдельно для Award?

0

@Cupko

ResidentEve, Какая-то странная задача на понимание трехслойной архитектуры. И у вас вопрос скорей по проектированию слоёв, чем про саму архитектуру. А если речь идет об интерфейсах/абстракциях, тут уже надо понимать Принцип инверсии зависимостей.

DAL, а именно слой, у вас один, и содержит некоторый классы/интерфейсы для работы с данными. Т.е. ваше утверждение, что нужно делать два DAL - в корне неверно. Сколько классов/интерфейсов делать внутри DAL и что от чего наследовать - это уже относится конкретно к проектированию DAL слоя, которое в свою очередь в основном зависит от способа хранения данных. Вы можете, допустим, иметь два класса в DAL слое, а на BL - один, содержащий User вместе с Awards.

0

@ResidentEve

Да, скорее всего задача именно на понимание проектирования слоев, как Вы и сказали.
Правильно ли я понял, что в моем случае обязательно в DAL нужно добавлять второй класс, который будет работать в Awards? У меня есть в DAL'e сейчас класс UserDAL, получается что он содержит в себе List<User> и List<Awards>. Это неправильно? Нужно ли создавать в DAL'e новый класс AwardDAL и чтобы он хранил в себе только List<Award>, а UserDAL - только List<User>? Или это не обязательно? Мне важно понять, как правильно или понять, можно ли сделать и так и так?

0

@Cupko

Это зависит много от чего: от того, является ли Award сущностью, или, допустим, атрибутом для User; существует ли Award без User и наоборот; есть ли возможность изменять сами классы; об отношении User-Awards; о способе хранения Award. Если Award у вас самостоятельная сущность, имеющая некоторые атрибуты - то да, нужен отдельный класс. Если Award у вас не существует без User, то отдельно List со всеми Award хранить бессмысленно, а User должен содержать в себе Award/коллекцию Awards.

1

@ResidentEve

Более-менее проясняется. Спасибо.

0