Back to list
Views:   0
Replies:  0
Long time... but thanks for the answer.
Jun 28, 2014
I wouldn't merge those two together since it's likely that, in the future you'll have a different set of dependencies with different layers. That being said, the typical way of handling this situation would be to divide the offending module into an interface library and an implementation library, and only creating dependencies from implementation to interface. For example, if I'd A -> B and B -> A, you would craft A : IA and B : IB, then recode so that A -> IB and B -> IA.
Aug 26, 2011
Reply 1
Hi ,

-----SEPARATION OF CONCERNS is the issue----------

More then any pattern you need to concentrate on one of the Key Architectural aspect "Separation of Concerns".

From your problem statement it is vivid that the few features your SL needs is coded in BL and the few features required for BL is coded in SL, thats why you ended up in referencing each other.

Per this architecture standard "All the functionalities that you need in BL should be encapsulated within BL."

In N-tier architecture SL is normally introduced to act as a mediator, that it totally abstracts away the dependency of PL on BL.

So that it introduces architectural stability/scalablity/flexibility etc., that any change to BL does not impact PL.

Also your BL mostly needs to be behind FireWall (FW) for security reasons.

Proposed Solution:

At this point if you need to encapsulate functionalities in web service and re-use across menthods in your BL ?

Then to resolve your issue you need to classify the web services on you service layer into two:

1-> PSL - Presentation Service Layer - the one which PL will have touch points to interact with BL back and forth.

2-> BSL - Business Service Layer - Accessible only for BL and not to out side world.

In your case the sequence could be like :

User-> PL -> <overweb access> PSL---|FW|--->B(S)L--->DAL---->DB

Hope this helps

- Tarriq Ferrose Khan

Tarriq Ferrose Khan, Aug 26, 2011
Stay Inspired!
Join other developers and designers who have already signed up for our mailing list.
Terms     Privacy     Licensing       EULA       Sitemap      
© Data & Object Factory, LLC.
Made with    in Austin, Texas