Hey Frans,

Wouldn't the following feature be interesting for LLBLGen :

http://community.devexpress.com/blogs/xpo/archive/2006/10/13/announcing-the-xpo-publication-service.aspx

http://community.devexpress.com/blogs/xpo/archive/2006/10/16/xpo-publication-why.aspx

http://community.devexpress.com/blogs/xpo/archive/2008/05/31/xpo-publication-service-update-for-8-1-4.aspx

So being able to natively do a publication of the generated datalayer by use of .NET Remoting or WCF and support a distributed model, that would be nice....

grtz, Danny

Isn't that what ADO.NET data services is going to put forward as well? (We'll have dataservices support soon)

Maybe so, but ADO.NET Data services is more web (REST) based while this seems to be a more flexible solution as you can choose to host your datalayer as a webservice or a .NET remoting/WCF based-host. Not stating that that is better solution though....

But you've planned support for these kind of features as well ?

Not really.

The thing is: having your datalayer without a REST layer exposed is really open for a 'chatty' service, not some service which is build on message based communication.

Also, our code is already easily exposed through WCF or remoting, so I think it's better if we leave it to the developers what to expose and at what abstraction layer. Personally I think a data-access layer exposed as a service is really not the way to go, I think mature, full stack webservices which act as standalone applications are better, and if that's not an option in an application, it might be the developer shouldn't opt for a 'service' at all. After all, designing the app around a service based architecture has to solve a problem, it's not some 'do this and it will be great' kind of technique.

OK, I see....so REST is a/the way to go for exposing data services ?

DvK wrote:

OK, I see....so REST is a/the way to go for exposing data services ?

It's 'a' way to do so, and IMHO if you want to use it as a low-level service, it's the best way. However developers should realize more than they do today that using a service isn't something that's required nor essential, it should only be used if it is a better solution than the alternatives. Services which are full applications (with a web interface) are IMHO preferable, as less traffic is going back/forth and more things are controllable. It is a bit more work perhaps, but in the end it's not really a problem, most work is in the maintenance of software anyway.