Data Transfer Objects using ADO.NET EF

All,

I'm new to creating n-Layered Applications and I'd like some insight.

I'm creating my first n-Layered Application and have a I have a PL, BLL, Service Layer (for responding to UI calls from flash and web components), and a DAL. I created these as separate projects so they would compile with their own DLL. However I found myself running into a circular reference problem because my SL had to have a reference to my BLL (to be aware of my Business Objects) and my BLL had to Reference my SL because at the time I didn't allow my PL to access my SL directly. Since then I moved my SL Logic into my BLL as separate class files (to be Business Object aware) .

So my questions are:
Is it good practice to move my SL to BLL?
What pattern should I employ to rid my self of circular references?

Finally,
I read about the Data Transfer Object Pattern(Value Object Pattern) and even though DoFactory employs this pattern in the "Patterns in Actions" Solution I cannot find where they explain it w/in the documentation (unless it's called something else) so I've been setting breakpoints to get the pattern flow.

Kevon Hayes, Aug 21, 2011

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