SOA Data Contract Patterns. I am sure the framework I am using introduces redundancy, anyone care to enlighten me?

Question

I'll start in the way most people seem to have taken to, on here....

So I was.... Nah thats gash. I'll start again (might lose a few points for not being straight to the point but wth)

Right,

I have inherited a framework which utilities WCF to provide some operation and data contracts.

This might be irksome to some, but I haven't done enough reading on SOA or WCF to garner knowledge about effective patterns (or best practices..) and therefore, don't really have a weighted opinion on my team on this subject, as of yet.

As an example in the framework I am using, there are a bunch of models for users.

Specifically we have the following models (data contracts):

• users_Loaded
• users_Modify
• users_Create

For all intents and purposes these data contracts are exactly the same - in so much that other than their "type", they have the same members and properties etc, and therein is my first problem.

The operations which utilise the data contracts have parameters which match the data contract you might want to perform some action with

Thus the operations utilising the data contracts:

• CreateUser(users_Create createdUser, ..., ...)
• ModifyUser(users_Modify modifyUser, ..., ...)
• GetUser(out users_Load loadedUser, .., ...) (out parameters on left most side of parameter list to boot!?)

Maybe the intent was to delineate the models and the operations from one another, but from my experience a method and its parameter list, usually give a good indication of what we are going to need to do.

Surely one data contract would have sufficed, and maybe even one operation (with a operation type parameter)

Am I missing the point. Why would you do what I have described?

Thanks.

i

Answer 1

It sounds like the previous developer(s) were either trying to implement some bastardized Command pattern, or they flat didn't understand WCF.

Long answer short, yes, from what you've said, you should be just fine combining these into a UserDto class that is the DataContract for all three operations. svcutil, for its part, should have no trouble generating one DataContract class on the client side that will work for all three OperationContract methods (or, since you seem to control both sides of this service, just use a shared assembly containing your DTOs on both client and server).