We are currently reviewing our WCF service design, and one thing that bothers me is the solution between the Per-Call and Per-Session services. I believe that I understand the concept of both, but I do not see the benefits of Per-Call services. I understand that the motivation for using Per-Call services is that the WCF service contains only the server object for the life of the call, thereby limiting the time when an expensive resource is stored by the service instance, but for me it is much easier to use a more OO-like Per- Session model, where your instance of the proxy object always corresponds to one instance of the server object and simply processes any expensive resources manually.
For example, let's say I have a CRUD service with adding, updating, deleting, selecting methods on it. This can be done as a Per-Call service with a database connection (an "expensive resource") created in the server object constructor. Alternatively, it could be a Per-Session service with a database connection that was initiated and closed in every open CRUD method.
For me, these are not different resources, and this simplifies the programming model, since the client can be sure that they always have the same server object for their proxies: any expensive state that may be between calls is saved and additional parameters are not required to determine what status data should be received by the service when the new server object is restarted (as is the case with Per-Call). This is exactly the same as using classes and objects, where the same problems of resource management are applied, but we do not create new instances of objects for each method call on our object!
So what am I missing in the Per-Call model?
thank
source
share