Hi,

I'm new to LLBLGen Pro (evaluating it, actually), and very new to WCF.

I've built code for a prototype project using the Adapter approach.

I want to get the client (win forms) talking to a WCF service for its data.

I think I'm OK with getting the service up and running, but what should I be using for proxies at the client - auto generated proxies, or the LLBLGen Entity classes themselves?

Any guidance would be appreciated. Thanks!

Are you using remoting or webservices? With 'webservices' I mean: real message based, contract first service oriented architecture.

I guess I'm not really sure. It seems to me at this point anyway that the lines between the two in the WCF world are much more blurry than they used to be.

Here's what I'm planning:

DB sits there happily. An app server sits between the DB and the Win Forms clients. And then the Win Forms clients are on top, with no ability to directly connect to the DB.

The app server has LLBLGen objects on it, and exposes them through wrapped LLBLGen Database Specific methods for loading and persisting those objects.

The objects are serialized and sent back and forth between the client and the app server.

So at the client, I need the interface, or I need to create proxies in Visual Studio like we did with web services. This is where it's not clear to me.

I guess this is really more a WCF question than an LLBLGen Pro question. I need to find a WCF book or something.

Thanks!

You could start with these easy articles: http://weblogs.asp.net/fbouma/archive/2006/11/10/Dennis-van-der-Stelt_2700_s-WCF-articles.aspx

And while you're at it: your setup sounds like it could use remoting perfectly. I'd go for that route first as you want to use entity objects on the client.

Though with all of this keep in mind that if you have an appserver serving your client, at which level do you want that app-server to be: at a low level so entities should be passed back and forth, or at a high level so command objects with DTO's should be passed back and forth.

Otis wrote:

Though with all of this keep in mind that if you have an appserver serving your client, at which level do you want that app-server to be: at a low level so entities should be passed back and forth, or at a high level so command objects with DTO's should be passed back and forth.

Frans - when you say dto's do you mean lightweight entity proxies (i.e. no entites are transferred) or cohesive entity containers whose payload may be entities that are required for a particular use case?

Thanks, I found that link (here) a couple of days ago and went through it. That's showing me how to do it in web services "mode" though, where I have VS create client side proxies. That just didn't feel right (because I'm leaving the Entity objects on the App server) and is what prompted this whole thing.

The only reason it's in the picture is to centralize the database connections. I can't have the connection coming directly from the UI (even if I wanted to) because the app this is replacing is running into problems due to the number of open connections to the database.

I'm somewhat concerned about passing the entire serialized Entity object over the wire, so maybe that low level approach is what I'm looking for. Minimize the size of the load going between the app server and the UI, and use the Entity objects at the UI.

I also hope to do some result caching at the app server so things like maintenance table data (lists that populate drop downs in the UI, etc) won't be retrieved from the DB every single time someone fires up the UI. But that's a little bit down the road. I just want to make sure I don't go with an approach that prohibits that in the future.

jaschag wrote:

Otis wrote:

Though with all of this keep in mind that if you have an appserver serving your client, at which level do you want that app-server to be: at a low level so entities should be passed back and forth, or at a high level so command objects with DTO's should be passed back and forth.

Frans - when you say dto's do you mean lightweight entity proxies (i.e. no entites are transferred) or cohesive entity containers whose payload may be entities that are required for a particular use case?

DTO's are buckets with data and no logic. I don't think proxy's are preferable, as property access would make the application pretty chatty and therefore could bring down the service.

DTO's are easy to generate and with the projection capabilities in llblgen pro, you can easily fill them with a couple lines of code using llblgen pro code. The other way around (DTO's coming from the client) is a bit harder I guess, but not much: fetch the entities, update the properties with the DTO data and save the entities.

DTO = Data Transfer Object. For web services it could be a class with nothing but public fields of scalar types, for instance.

Sorry guys - I used the term proxy incorrectly - I meant exactly what you describe - an object that only holds data. Next question...

In a "closed" system as described above (i.e. the services exposed by the middle tier will only be consumed by .net clients that are developed as part of the solution), why would you want to use DTO's? Having spent significant time building a highly functional entity layer on top of a great framework, it would seem strange not to leverage that on the client as well by transferring the entities themselves. I agree that the level of the conversation should be carefully considered and that a messaging / command based approach may well be the right design choice but why should that preclude the transfer of the entities themselves?

I'm more familiar with webservices than remoting, but I believe remoting would be a better choice if you don't want to pass DTO's around between servers. i.e. it's easier to pass LLBLGen objects around using remoting than it is using webservices. The drawback of course with remoting is that it is platform-specific, but that may not be an obstacle in your case.

The more I think about it, the more I think what I really want to do (in my situation) is to expose parts or all of the DBSpecific project in a MarshalByRefObject in Remoting. And then when I can figure out how to move that to WCF I will.

So my DBGeneric stuff will be referenced by the Win Forms client, and each of the calls to the DataAccessAdapter will be going over the wire to my remote object hosted in IIS.

That would avoid the chatty property access problems because the DBGeneric Entities would reside with the client, and I wouldn't have to map to custom and redundant DTOs.

Is there an easy way to expose the DBSpecific methods through remoting or do I have to create interfaces and share them?

Thanks!

The adapter object isn't remotable because it contains a connection. So if you want that object to be remotable, you've to wrap the calls into a service.

Though, it's often better to build a high-level service than a low-level service. the low-level service creates a lot of overhead and gets called much more often and you basicly then are re-doing the low-level app-> db transport layer but with much more overhead.

Let me step back a bit. I'm talking about using the generated DBGeneric objects on the client, and exposing the functionality of the DBSpecific objects on an app server. So the data passed between the app server and the client would be serialized DBGeneric objects.

The business objects on the client would know how to consume the DBGeneric objects, and how to load and save them effectively for the UI (in one fetch, give me everything I need for this screen).

If that's what you call a low level service, then I assume by high level service you mean the DBGeneric objects would be staying on the app server, and I'd be passing data between the app server and the UI in business objects using methods like "Get all of the purchases for customer X." Is that correct?

That sounds it would lead to a lot more code duplication than what I had in mind, as well as being more chatty, so I must not understand what you mean.

Seems to me a lot of the power of using the DBGeneric objects lies in the fact that I can create the structure I need to use in a specific page/form in the UI, and then go get it loaded in one fetch. Or maybe two or three, but that's better than a lot of the "pure OO" designs I've worked on in the past where objects load themselves causing 200 or 300 round trips to render a page or display a form.

If I leave the DBGeneric objects on the app server, I lose that power. But again, maybe I misunderstand.
Thanks again.

Hello,

you can have a methods like "Get all of the purchases for customer X." on the server side but the method will send an entityCollection so you could use your dbGenerics on the client side. So you will expose the functionnality of DBGenerics Object that will call dbSpecific. So in that way you never expose the DBSpecific objects but you will expose dbgeneric that you could use directly in the client side.

Hi, and thanks.

Actually, I wasn't really going for a true service layer (service application), with methods like Get all purchases for customer X. Of course it would be cool to have that separation, but it would also increase the amount of code required to give the customer what they want by a significant percentage. I understand the value of loosely coupled tiers (at least I think I do), but I do not think there is always a strong enough reason for it to justify the extra work required to design and implement it. Every project has different requirements and motivation.

What I was planning on using LLBLGen for is simpler. UI talks to Business objects which assemble LLBLGen Entities and collections, extending as required with business rules. And a service that I can use to load and save the business object (set of related LLBLGen entities) efficiently (least round trips possible). This is basically a client/server app. The only purpose for the service layer in this approach is to gather all of the database access and deploy it on a set of machines v. having each client PC directly accessing the database.

Thanks again.

diz wrote:

Hi, and thanks.

Actually, I wasn't really going for a true service layer (service application), with methods like Get all purchases for customer X. Of course it would be cool to have that separation, but it would also increase the amount of code required to give the customer what they want by a significant percentage. I understand the value of loosely coupled tiers (at least I think I do), but I do not think there is always a strong enough reason for it to justify the extra work required to design and implement it. Every project has different requirements and motivation.

What I was planning on using LLBLGen for is simpler. UI talks to Business objects which assemble LLBLGen Entities and collections, extending as required with business rules. And a service that I can use to load and save the business object (set of related LLBLGen entities) efficiently (least round trips possible). This is basically a client/server app. The only purpose for the service layer in this approach is to gather all of the database access and deploy it on a set of machines v. having each client PC directly accessing the database.

Thanks again.

Hey Diz,

You're not alone http://www.llblgen.com/tinyforum/Messages.aspx?ThreadID=8174

Jascha