tags:

views:

32

answers:

1
+1  Q: 

WCF DAL COMPONENT

I have a DAL that is replicated across multiple apps (I know its a bad design but ignore this for now) , what I want to do is this...

Create a WCF DAL Component that will be accessed via all Desktop apps.. Could anyone share their thoughts on following ??

  1. I am intending to use TCP Binding
  2. What will be the overhead in terms of performance ( since 1 DAL component will b consumed via multiple apps )???
  3. Since TCP Binding can only be hosted on IIS-7.0, this will be another overhead in terms of hardware+s/w ( or is it possible to have HTTP binding at top and TCP beneath that so that I can use IIS version 5 or 6 )???
  4. Can I have multiple end points for multiple apps and is good from performace point of view as it will help us creating different thread for different client apps and can have diff contracts in future as well so that one application goes unaffected due changes in the DAL..
  5. What Instancing Mode is preferred in this case (we are expecting a traffic of 100 concurrent user per day) , and DAL already handles this using SINGLETON design pattern.

Let me know your thoughts on all of above mentioned points and also if you could provide me more insight on this... will b gr8.

Thanks in advance...

+2  A: 

Let me answer a few:

1) netTcpBinding is a great binding - very fast, very good in performance - definitely go with that!

3) Either host in IIS 7.0, or then self-host - write a little Windows NT Service and handle the hosting yourself. Gives you more control, and the ability to manually start and stop your DAL Service. I wouldn't even bother trying to get NetTcp working on IIS5/6 with some kind of a trick/hack - waste of time.

4) Multiple endpoints of the same binding are neither useful, nor do they help with performance.

5) I would always use "Per-Call". Each service request gets its own instance of the service, the call is handled, and then you're done. That makes programming the WCF service implementation a snap - if you go singleton, to have any performance at all, you need to worry about multi-threaded and thread-safe programming - a mess, really. Don't do it. NO, just don't do it.

A DAL should always be stateless and should operate on the "open the database connection as late as possible, do the work, and close the connection as soon as possible" again pattern which is a perfect fit for the per-call instance mode. When your service request comes in, the connection is opened (those are pooled in a connection pool in ADO.NET anyway, on the server side), the works is done, and the connection is closed again.

marc_s
Thanks marc_s,1 more query- As per your reply --> again pattern which is a perfect fit for the per-call instance mode. When your service request comes in, the connection is opened (those are pooled in a connection pool in ADO.NET anyway, on the server side), the works is done, and the connection is closed againDoes this means that this apply only for Per Call ?? If yes then what for other 2 options ( Single and Per Session )
Amit
@Amit: if you use per-session, I would still open the connection for each service method, do what you need to do, and close it again. In the case of the singleton, you have two options: do it that way, or keep one connection open at all times and do all your requests over that one connection. However: this gets really hairy and challenging when you have multiple simultaneous requests being handled by the singleton at the same time..... I wouldn't want to make sure nothing goes wrong in that case.... very very tricky business.....
marc_s