2

Not too long ago I started a new job where they've been using WCF for all data/business logic between UI and backend which is great.

Something I've noticed is that the vast majority of these WCF service calls contain a variety of parameters. For instanced, say you have a service call called GetFoo. Here we might use a signature as follows:

public Foo GetFoo(int? ID, string Name, DateTime? fooDate)

For a more object-oriented approach you might instead use:

public Foo GetFoo(Foo foo)

In this case, the code grabs what it needs from the Foo POCO object instead of depending on a specific set of parameters passed in from UI.

On the one hand this provides a more flexible contract between UI and WCF Service. We can make changes to implementation on service side without breaking any contract and updating references. Additionally, we can have business object which acts upon the POCO directly vs. dealing with an explicit list of parameters.

On the other, it is not clear what is needed in order to get the objects/data you want back.

Which approach would be considered best practice?

Peter
  • 27,590
  • 8
  • 64
  • 84
Jacob Rutherford
  • 584
  • 3
  • 11

4 Answers4

1

I always go for single parameter in and out. That parameter defines the message (or at least the message body) for the data I am expecting and the return defines the message body I am going to send back

You retain little control over what the message looks like on the wire if you use multiple parameters.

The fact that contract operations are .NET methods is an implementation detail. The goal of the contract is to define the structure of messages between consumer and service.

Richard Blewett
  • 6,089
  • 1
  • 18
  • 23
1

I'd suggest a third, more verbose approach:

public Foo GetFooByName(string Name)
public Foo GetFooByIDAndName(int ID, string Name)
public Foo GetFooByNameAndDate(string Name, DateTime fooDate)
public Foo GetFooByIDNameAndDat(int ID, string Name, DateTime fooDate)

And so on and so forth. In order to DRY, you might extract common code and make some private methods. This leads to self-descriptive code, and errors can be pinpointed with much more accuracy (not to mention you can change a single method while leaving the others unaffected, which is always good).

Alex
  • 23,004
  • 4
  • 39
  • 73
  • I can dig that. The service calls are explicit, and the intent is obvious while the underlying implementation is cohesive. – Jacob Rutherford May 15 '12 at 11:13
  • You can also split them up in `partial` classes like this, if you want to, and multitask the development. Also, simple types mean easier interoperability (you never know when a wild java client will show up...) – Alex May 15 '12 at 11:20
0

You can have both, but it should be clear what they mean. Both methods you have now are not clear on what they do. The first one:

what happens if I pass a:

ID = 1
Name = "Name"
fooDate = NULL

Then I ask for item with id = 1 and name = "Name" OR do I ask for id = 1 and name = "Name" and fooDate = null or do I ask for id = 1 or name = "Name" ro fooDate = null.

In this case at leasest the Id should be a seperate function.

In you second sample you have make a function which I whould call get by example. However hou can't ask for specific NULL values. Besides that I would not call it a object-oriented apprach because you pass in a object. OO is more about how objects interact with each-other.

In choosing an approch, be more explicit in what your function does. If you do need a function where you can pass in an object and build a dynamic query. Call the function GetFooByFooExample. However if you only fill the id, consider a function like GetFooById, which makes your code far more readable and self explaining.

Peter
  • 27,590
  • 8
  • 64
  • 84
  • WCF by definition is service based, however, you can implement it in an OOP fashion if you pass in an objects which dictate behavior vs. explicit service calls to handle each scenario. I believe both approaches have positives and negatives, though my instinct would be to utilize the OOP approach as much as it makes sense. – Jacob Rutherford May 15 '12 at 10:40
0

OOP is what most of us strive for. What if you realize that, you'll need a new attribute on the Foo object and the Foo object has 15-20 methods which have sub methods and so on, this is just smelly code and it will save you time to do the right thing (oop imo :) ).

How many parameters are too many? more info

I would recommend that you look into Martin Fowlers book about refactoring he says what most of what programmers think but for some reason we don't do.

Community
  • 1
  • 1
Thomas Lindvall
  • 599
  • 6
  • 13