Business Logic Layer Design

Question

Я чувствую себя таким нубом, чтобы задать этот вопрос, но это уже давно подтачивало меня.

При проектировании BLL многоуровневого приложения вы бы поместили все классы сущности в одно пространство имен? Например: если у вас есть база данных с Клиентами и их Транспортными средствами, и эти Транспортные средства получают обслуживание, можно сказать, что ежемесячно. Я бы подумал, что один из них будет держать клиентов и их транспортные средства в отдельном «модуле» из «сервисного модуля» (так что, если вам когда-либо понадобится обновить способ обслуживания или где хранятся данные, вам не нужно прикасаться модуль Customer \ Vehicle).

Правильно ли я размышляю об этом или должен изменить свои дизайнерские идеи?

Это привело к возникновению проблемы с использованием LINQ to SQL. Если половина классов сущностей таблиц содержится в «модуле» A, а другая в «модуле» B, то где-то вы будете иметь «модуль» ссылочный «модуль» B и наоборот, чтобы учесть ассоциации между двумя таблицами, которые границы с «модулями».

ИЛИ (только подумал об этом сейчас) у вас будет 1 класс сущностей таблицы в «модулях» (с тем же классом в обоих модулях)?

Любые советы будут оценены.

Answer 1

Не совсем понятно, если у вас также есть уровень доступа к данным, потому что вы указываете «так, что если вам когда-либо понадобится обновить способ выполнения сервисов или где хранятся данные, вам не нужно прикасаться к Клиенту \ Автомобильный модуль ". DAL позаботится о том, чтобы обрабатывать извлечение и хранение данных, где бы это ни было.

Но, конечно, может быть, что Автомобиль должен быть обновлен, и было бы очень удобно, если бы обновление этих правил нужно было сделать в одном месте. Вы могли бы просто создать клиент и автомобиль BLL с этими правилами. Затем вы просто добавляете CustomerVehicleService, в котором используется Клиент и Транспорт. Нет правила, которого вы не можете.