-1

Hi I have been reading some lecture notes and I cant work out why this method:

[OperationContract]
Student PostStudent (Student student);

Is good.

And this method is bad:

[OperationContract]
void PostStudent (string firstname, string lastname etc..);

Yet my implemented version is this:

[OperationContract]
void PostStudent(Student student);

So Im not sure if my implemented version is bad, Im also unsure how my lecturer got

Student PostStudent (Student student); // ?

James A Mohler
  • 11,060
  • 15
  • 46
  • 72
G Gr
  • 6,030
  • 20
  • 91
  • 184
  • 3
    Can you elaborate on what you mean by "this method is bad"? – mgnoonan May 03 '12 at 11:11
  • I can only see the method being `bad` by having an excessive number of method parameters (how many did you leave out in `...`). You could also nitpick that it does not use camel casing for parameter names, but otherwise there's not really anything bad about it. – David Anderson May 03 '12 at 11:20
  • My preference towards what your lecturer describes as the "good" implementation is also based on the fact that it's input type is a `Student` rather than a bunch of strings. This should make confusion about the meaning of each parameter less likely. But it also prevent REST-style URL-mapping of parameters if you should decide to do that later. – faester May 03 '12 at 11:45
  • @mgnoonan exactly what I said thats all he has in the slides. I could post a screen dump of it but its exactly what I mention. – G Gr May 03 '12 at 11:45
  • @faester I thought url mapping was to direct documents, i.e you should never map to Student/Student.xml? – G Gr May 03 '12 at 11:47
  • @JungleBoogie: It is really another discussion. Sorry I brought it up. In this case it would probably not make much sense, but URL's could map to a student in other cases using ids, or search parameters. But ignore my comment, it isn't that relevant here. – faester May 03 '12 at 11:49

4 Answers4

3

Web services are built upon the use of messages. A message in WCF is defined by writing a class, which your Student class is, and (optionally) marking it with the DataContract attribute. This enables versioning and setting various properties on the properties of that class (although the latter effect can also be achieved using the MessageParameter attribute).

So yes, PostStudent (string firstname, string lastname etc..) is bad.

Whether or not to return something from that method is up to you. A void can be perfectly fine, because using for example SOAP you can return a Fault indicating why the user could not be created: no error means the creation went well.

When you want to inpect the created Student, you might as well define a PostStudentResult (or a PostResult<T>) class and return that, containing the properties Student (or T Result) and Status, where the first contains the student as it's created and the latter indicates whether or not the creation was successful.

Community
  • 1
  • 1
CodeCaster
  • 147,647
  • 23
  • 218
  • 272
  • 2
    +1 To me the main difference in the "good" version, is it is more future proof... it deals with versioning much better. http://msdn.microsoft.com/en-us/library/ms731060.aspx – Kenneth Ito May 04 '12 at 16:49
0

Return values in Web services are not bad practice in general. So it is about the parameters. Data that belongs together should be wrapped in in Objects.

Further a Post method should not get an return value at all. You post it and in case of an error your will receive an Exception.

If your need to receive some student you should create an method like:

Student GetStudentByName(string name);
Tarion
  • 16,283
  • 13
  • 71
  • 107
0

If it is a WCF then specifying Action can also be a good practice with Void methods.

Deepesh
  • 5,346
  • 6
  • 30
  • 45
0

Like evryone else said, having too many method parameters is bad practice. Any way I can see only one difference between your signature and the good signature you mentioned. Having the student object as return will give you the ability of having the Id of the student after addition in db for example. Same thing applies for any other calculated properties of the object. Have a void method will force you to load the object again which means an extra trip to server in case you wanted to use the object directly after posting it. Any way having void WCF method is not bad if returning the object is nothing but an extra bandwith.