Hi,

I'm on the verge of creating a brand new platform for a new client where I'm in the position of making decisions for the architecture and frameworks. The platform will encompass several applications (WPF or silverlight "fat clients", some web sites for reporting and consulting, ..) all working on the same data. The platform will be used by a few hundred users in several subsidiaries in different continents (US, EU, AU, Asia..). Due to limited technical experience and very strict FDA-regulated privacy issues, we are not sure we want to move to the cloud. Also the platform will not need the massive scalability the cloud typically offers. So that leaves us with a standard WCF-based architecture.

I'm thinking about using LLBLgen for the datalayer. In the past few years I've had some bad experiences with nHibernate, good experience with L2Sql, and not so much with EF. My last (very good) experiences with LLBLGen date from 2005, but it was a big client-server application. WCF (still Indigo then) was not all that hot back-then But I have some questions of how to tackle the problem of working with the data in the fat clients (eg. WPF smartclient app).

I see two main possibilities:

• serializing the LLBLGen entities in the WCF calls to the client. (there was an article on the forums a while ago on how to do it with a custom datacontractserializer and that works nicely). This gives the benefits of not having to make DTO's, free client side entities, and I'll get all the built-in support for INotifyPropertyChanged in the LLBLGen entities for free. But in this secenario I'll have a dependencecy on the ORMSupportClasses and DatabaseGeneric dll on the client ...

• just use LLBLGen on the backend, and return DTO's to the client. That seems a whole lot of extra manual work (poco's and client side entities) to me once you start having lots of tables. But it's more "poco" style and there's no dependency on the client for any LLBLGen dll's ...

I imagine this problem must have been tackled many many times before since most architectures nowadays use the datalayer-backend-wcf-frontend approach ? What's your take on this ?

IMHO, since these are fat clients, then I suggest using LLBLGen Entities all the way. Otherwise if they were thin clients, I'd say use the DTOs.

Hello!

Where might this article be that was mentioned below? I too am doing a WPF/WCF app and need a bit more guidance on the best approach to use WCF with WPF..

Thanks! Harold

HcD wrote:

Hi,

• serializing the LLBLGen entities in the WCF calls to the client. (there was an article on the forums a while ago on how to do it with a custom datacontractserializer and that works nicely). This gives the benefits of not having to make DTO's, free client side entities, and I'll get all the built-in support for INotifyPropertyChanged in the LLBLGen entities for free. But in this secenario I'll have a dependencecy on the ORMSupportClasses and DatabaseGeneric dll on the client ...

hchattaway wrote:

Hello!

Where might this article be that was mentioned below? I too am doing a WPF/WCF app and need a bit more guidance on the best approach to use WCF with WPF..

Hi Harold. I don't know exactly what is exactly that article. However you can start trying the documentation says about WCF and how to make it work.