Здравствуйте, lumf, Вы писали:
L>должен ли Service Layer(Application logic) знать о Data Access Lyaer или же он должен работать только Business Logic Layer?
Зависит от реализации ващей архитектуры ....
В теории не должен знать
Здравствуйте, lumf, Вы писали:
L>Здравствуйте, kisel, Вы писали:
K>>В теории не должен знать
L>ну я понимаю, что лучше как можно сильнее расслоить систему.... но чем грозит моя ситуация?
Поддержка,масштабируемость
короче у меня есть три слоя.... Service Layer (Application Logic), BLL , DAL. По идее Service Layer не должен ничего знать о DAL. В BLL у меня есть два класса Task , TaskCollection. В DAL у меня есть TaskGateway(шлюз таблицы) Вот перечень действий, которых мне нужно совершать с Task: считать за раз N Task, обновить статус одной Task, может быть обновить статус N Task. Логично, что все этой умеет TaskGateway. так как Service Layer не должен общаться с DAL то сообтветственно в BLL должен быть некий класс грубо говоря оболочка над TaskGateway. Вот как назвать этот класс? и желательно еще бы понять как он классифицируется(к примеру по Фаулеру)
Здравствуйте, lumf, Вы писали:
L>или лучше на конкретном примере:
L>короче у меня есть три слоя.... Service Layer (Application Logic), BLL , DAL. По идее Service Layer не должен ничего знать о DAL. В BLL у меня есть два класса Task , TaskCollection. В DAL у меня есть TaskGateway(шлюз таблицы) Вот перечень действий, которых мне нужно совершать с Task: считать за раз N Task, обновить статус одной Task, может быть обновить статус N Task. Логично, что все этой умеет TaskGateway. так как Service Layer не должен общаться с DAL то сообтветственно в BLL должен быть некий класс грубо говоря оболочка над TaskGateway. Вот как назвать этот класс? и желательно еще бы понять как он классифицируется(к примеру по Фаулеру)
Не знаю как там по Фаулеру не читал ...Названия — условности...
Общее у слоёв Service Layer,BLL,DAL это сущности которыми они оперируют, логично создать отдельную сборку BusinessEntity, на которую бы ссылались и оперировали эти слои.
DAL — взаимодействие с СУБД
BLL — реализация бизнесс логики
Service Layer — реализовывает бизнесс логику приложения, если ты будешь из Service Layer обращаться к DAL, тогда ты завязываешь логику приложения на работу с одной СУБД, что не есть масштабируемо ... используя цепочку Service Layer <==> BLL <==> DAL ты это го избежишь, потому как BLL инкапсулирует в себе сведенья о СУБД и Service Layer не завязывается на СУБД ...
Хорошо выполнять все бизнесс правила в одном слое, он является своего рода Фасадом к DAL, таким образом код лечге поддерживать ... а если начать дергать DAL из Service Logic или Presentation Layer , тогда вообще бардак получится, со временем можно запутаться, что где вызывается ... и масштабируемотсть при этом падает ...
Здравствуйте, stump, Вы писали:
S>Здравствуйте, lumf, Вы писали:
L>>ну я понимаю, что лучше как можно сильнее расслоить систему.... но чем грозит моя ситуация?
S>Например тем, что изменения в Data Access Lyaer могут повлечь изменения в Service Layer, чего хотелось бы избежать.
ну как бы могут..... но я пока вижу какие изменения в DAL: это смена БД ..... то есть я просто перепишу DAL и ничего в service layer править не буду...
а если придется править service layer то это уже меняется логика приложения, так? а какие изменения в DAL могут повлечь за собой изменения в service layer ?
K>Не знаю как там по Фаулеру не читал ...Названия — условности... K>Общее у слоёв Service Layer,BLL,DAL это сущности которыми они оперируют, логично создать отдельную сборку BusinessEntity, на которую бы ссылались и оперировали эти слои. K>DAL — взаимодействие с СУБД K>BLL — реализация бизнесс логики K>Service Layer — реализовывает бизнесс логику приложения, если ты будешь из Service Layer обращаться к DAL, тогда ты завязываешь логику приложения на работу с одной СУБД, что не есть масштабируемо ... используя цепочку Service Layer <==> BLL <==> DAL ты это го избежишь, потому как BLL инкапсулирует в себе сведенья о СУБД и Service Layer не завязывается на СУБД ... K>Хорошо выполнять все бизнесс правила в одном слое, он является своего рода Фасадом к DAL, таким образом код лечге поддерживать ... а если начать дергать DAL из Service Logic или Presentation Layer , тогда вообще бардак получится, со временем можно запутаться, что где вызывается ... и масштабируемотсть при этом падает ...
да суть выделения в слои мне понятна... может я просто как-то DAL не так реализую.... у меня DAL знает о некоторых объектах BLL, чтобы к примеру вернуть мне сразу проинициаизированную коллекцию(в моем случае TaskCollection), то есть если я вроде как не привязываю Service Layer к базе данных(бд смнится---я просто перепишу DAL и все, service LAyer это никак не затронет)
Здравствуйте, lumf, Вы писали:
L>должен ли Service Layer(Application logic) знать о Data Access Lyaer или же он должен работать только Business Logic Layer?
В твоем случае я считаю можно сделать так, чтобы Service Layer(Application logic) работал с Data Access Layer.
Почему? Это потому что ты сам не пожешь понять, зачем тебе сильно расслоение А тебе лучше знать
Здравствуйте, Дмитрий В, Вы писали:
ДВ>Здравствуйте, lumf, Вы писали:
L>>должен ли Service Layer(Application logic) знать о Data Access Lyaer или же он должен работать только Business Logic Layer?
ДВ>В твоем случае я считаю можно сделать так, чтобы Service Layer(Application logic) работал с Data Access Layer. ДВ>Почему? Это потому что ты сам не пожешь понять, зачем тебе сильно расслоение А тебе лучше знать
а вот объясните мне плиз..... я вообще думал что есть некие концепции архитектуры, которых следует придерживаться...... то есть расслоение не всегда нужно что ли? ну хотя бы такого рода как в моем примере.... можно конечно примерно прогнозировать возможные изменения в слоях, но слои ведь не только для того масштабируемости и легкозаменяемости, но и для удобочитаемости.... разве не так? или в моем случае Service Layer по каким-то причинам не стоит отделять от DAL?
Здравствуйте, lumf, Вы писали:
L>а вот объясните мне плиз..... я вообще думал что есть некие концепции архитектуры, которых следует придерживаться...... то есть расслоение не всегда нужно что ли? ну хотя бы такого рода как в моем примере.... можно конечно примерно прогнозировать возможные изменения в слоях, но слои ведь не только для того масштабируемости и легкозаменяемости, но и для удобочитаемости.... разве не так? или в моем случае Service Layer по каким-то причинам не стоит отделять от DAL?
Для деления приложения на логические слои есть только одна причина — сие есть одна из техник проектирования, позволяющая преодолевать (бороться со) сложность(ю) создаваемой системы в процессе разработки.
Для деления приложения на физические уровни (tiers) причина другая. Это способ справится с большой нагрузкой, которая неподъемна для монолитных или клиент-серверных приложений и добиться лучшего масштабирования.
Об этом часто забывают.
Здравствуйте, lumf, Вы писали:
L>Здравствуйте, stump, Вы писали:
S>>Здравствуйте, lumf, Вы писали:
L>>>ну я понимаю, что лучше как можно сильнее расслоить систему.... но чем грозит моя ситуация?
S>>Например тем, что изменения в Data Access Lyaer могут повлечь изменения в Service Layer, чего хотелось бы избежать.
L>ну как бы могут..... но я пока вижу какие изменения в DAL: это смена БД ..... то есть я просто перепишу DAL и ничего в service layer править не буду...
L>а если придется править service layer то это уже меняется логика приложения, так? а какие изменения в DAL могут повлечь за собой изменения в service layer ?
Неизменным должно быть API слоя (фасад, интерфейсы, сигнатуры методов), чтобы не пришлось менять "вызывающий код". Меняться может реализация, в том числе база. Другое дело, если вызывающий класс занимается еще и инстанцированием объектов а класс под другую базу подругому называется.Можно юзать абстрактную фабрику, но опять же не знаю, как она будет вид базы узнавать (может из конфигов?), а можно вообще заюзать контейнер для Dependency Injection.здесь пример фреймворка от M$.
...Названия — условности...
