I've read over the posts on Self-Service and WCF and the also the help where it says that if you are doing Web Services or WCF, you should use Adapter. In our application, we have a Windows Service that hosts a WCF Service. We also have a client GUI application that consumes the WCF service. In this scenario, both Client and Windows service can see the database and interact with it. In fact, both do for all other aspects of their functionality and only about 5% of their functionality is talking to each other.

In this scenario, am I still okay using Self-Service or is there some inherent reason that this won't work. Obviously the code is more compact and easier to work with than Adapter and I can take advantage of the lazy loading etc. that self-service offers.

Thanks,

Allen

• if you want to transport entities over teh wire: Adapter is the only option
• if you want to transport ONLY DTO classes and all persistence stuff etc is encapsulated inside the webservice you can use both SelfServicing or Adapter.

Another related info: http://llblgen.com/TinyForum/Messages.aspx?ThreadID=11615&StartAtMessage=0&#64634

Thank you for the link. I had previously read that portion of the documentation.

Pardon my questions, I'm still learning LLBLGen. The documentation says that the reason that you can't use Self-Servicing is that if someone walks a child relationship, the database isnt available and it will cause an error. In my case, everything is running on the same local network. While I am using WCF for cross session communication (the service runs in session 0 on Vista and the client app is in Session 1 but it is all on the same computer), I am not using a distributed scenario (communication over the web, etc.). Is there some other reason that Self-Servicing doesn't work. Are the entities not serializable? Some other reason?

Thanks for helping me understand this better.

For web services and WCF, which both use the IXmlSerializable implementations of the entity and entity collection classes, LLBLGen Pro uses its own Compact25 format, which is very lightweight and very fast to consume and produce as it contains almost no overhead. See for a description of the Compact25 format, which is Adapter specific.

asowles wrote:

Thank you for the link. I had previously read that portion of the documentation.

Pardon my questions, I'm still learning LLBLGen. The documentation says that the reason that you can't use Self-Servicing is that if someone walks a child relationship, the database isnt available and it will cause an error. In my case, everything is running on the same local network. While I am using WCF for cross session communication (the service runs in session 0 on Vista and the client app is in Session 1 but it is all on the same computer), I am not using a distributed scenario (communication over the web, etc.). Is there some other reason that Self-Servicing doesn't work. Are the entities not serializable? Some other reason?

Thanks for helping me understand this better.

Why are you using a webservice if it's on the same computer? That's overhead which is really not that useful. using selfservicing will also break encapsulation, because you might fetch a customer over WCF and pass it to the client, however the client has to have the DAL locally and a connection string when you, in the client app, touch the Orders collection: it will fetch that collection on the client directly from the DB, bypassing your WCF service. This is particularly dangerous when you in the future decide to run the service on another system: it then will also break. But the bypassing of your service is already a showstopper: don't do this.

I.o.w.: either remove the service, or use adapter. Walaa describes Compact25, however that's only available in adapter, as it's meant for xml serialization which won't be used in selfservicing: lazy loading prevents selfservicing from being suitable for service oriented architectures, and also because selfservicing code has fetch logic in the entities (as it's selfservicing) as well as persistence logic, so it will always work through its own code with the DB, never with your service. Adapter has a split design: entities and persistence logic are completely separated: so you can use the entities on the client and you always have to consult the service, which is the purpose of the service in the first place.

I.o.w.: don't use selfservicing in a distributed system, even if they're running on the same computer, it's still a distributed system. Use adapter in these scenarios. If you still want to use selfservicing, drop the service (as you won't need it anyway, I don't see why one would want a slow service on the same computer as the client) and use a normal app architecture.

Thanks everyone for the comments. The reason I am using WCF on the same computer is to work around the session issue on Vista and now Windows 7. My Windows Service and my GUI App use custom Listener objects to pass information back and forth to each other. Most of the time, these are status events, event "bubble-ups" and such. In XP, where the service and the app both ran in Session 0, this wasn't an issues, but with Vista and Windows 7 and beyond, all services run in Session 0 and any apps, even what we used to traditionally think of as "console", run in session one. I am using WCF to bridge that gap and it works very well for this.

In my scenario, the Windows Service reads from a common "config" file that has the DB connection string on startup. The GUI does the same. Both apps are responsible for managing their own connections to a common database server. I don't route all traffic through the windows service. For 95% of the time, they are really doing different things. It's only occasionally that they send information back and forth to each other.

I'll follow your advice and set up custom DTO objects for passing back and forth between the apps. I was hoping to avoid the "packaging and unpackaging" of the DTO objects, but that's okay for what I need to do.