Hello, I am actually looking at the 2.5 version which looks great, plenty of good new stuff, well done!

About using LlblgenPro in a distributed scenario, with WCF, here is an extract of the documentation:

“If you want to have a fixed DataContract instead, you shouldn't use Entity classes but you should send Data Transfer Objects (DTO)'s which are more or less dumb buckets with data back and forth. The reason is that a DataContract can't change however an entity might change over time, which then would violate the DataContract"

Is this statement a general recommendation/best practice? Or is it something mandatory and if you try defining a data contract using Entities it would simply not work?

The thing is that in my understanding, we actually have the same issue using “classical” web services in .NET 2.0 when defining a service method like the following:

[WebMethod] public CustomerEntity GetCustomer(string customerID)

In a service oriented approach, you are not supposed to break the contract unless you version your service and thus create a new version of it whenever you change the contract. And if you change the CustomerEntity class then the contract is broken and you should have a new version.

The fact is that using entities objects is really great as it comes with the full fledge functional data binding experience in .NET, which we wouldn't get using DTO objects... I understand that in a fully service oriented approach, it’s just not so good to share object implementation across client and server but it is a very good compromise in full .NET implementations.

So question is: what makes the use of Entity classes in a service interface different from .NET 2.0 and .NET 3.0/WCF?

Thanks in advance

Walter wrote:

Hello, I am actually looking at the 2.5 version which looks great, plenty of good new stuff, well done!

About using LlblgenPro in a distributed scenario, with WCF, here is an extract of the documentation:

“If you want to have a fixed DataContract instead, you shouldn't use Entity classes but you should send Data Transfer Objects (DTO)'s which are more or less dumb buckets with data back and forth. The reason is that a DataContract can't change however an entity might change over time, which then would violate the DataContract"

Is this statement a general recommendation/best practice? Or is it something mandatory and if you try defining a data contract using Entities it would simply not work?

The core point about a datacontract is that it is set in stone and will not change. This means that you start with the contract and then write code to be sure that the contract is obeyed.

The format of the XML produced by LLBLGen Pro isn't set in stone. So it's not clever to rely on that as your contract.

Another thing is that by using DataContract attributes, you will let the WCF xml serializer do its job. That's a tough call, as it will likely have a big problem serializing the data, as it always had as some members are interface based.

The thing is that in my understanding, we actually have the same issue using “classical” web services in .NET 2.0 when defining a service method like the following:

[WebMethod] public CustomerEntity GetCustomer(string customerID)

In a service oriented approach, you are not supposed to break the contract unless you version your service and thus create a new version of it whenever you change the contract. And if you change the CustomerEntity class then the contract is broken and you should have a new version.

Correct.

So you should use messages instead: instead of passing entities, you should create a message based service.

I always found it odd to use webservices when entities were passed back and forth, as both sides apparently were .net applications.

The fact is that using entities objects is really great as it comes with the full fledge functional data binding experience in .NET, which we wouldn't get using DTO objects... I understand that in a fully service oriented approach, it’s just not so good to share object implementation across client and server but it is a very good compromise in full .NET implementations.

So question is: what makes the use of Entity classes in a service interface different from .NET 2.0 and .NET 3.0/WCF? Thanks in advance

I don't fully understand the last question but I assume you wonder what's different with using entities in .net 2.0 webservices compared to wcf? Nothing. Well, of course in WCF you can define a service contract, and you then don't have to mess with schema importers and other crap (whoever cooked that misery up over at MS is hopefully fired)

If you want entities to be passed back and forth, use remoting with the new fast serialization feature.