Generics and convention in C# Generics and convention in C# asp.net asp.net

Generics and convention in C#


I don't see a problem with this use of generics, unless you would have someone using your service from something other than .NET perhaps. I think it generates quite ugly contract names for the WSDL.

So for your use case, I'd say it's fine. I'm glad you changed from Model to Response as well. I was going to suggest that.

Depending on how the errors are used, I would personally prefer to raise an (aggregated) exception for them. However, if you use it for forms validation or something, I would say that's acceptable.


Probably my answer is too subjected as well - but I'd suggest avoiding creation of dependencies before you have a stable working system at least in beta version. Especially when you're at the beginning of development. Also as inheritance in one of the strongest relation types, it should be put aside as long as possible.

Adding base class or generic, which looks the same, you put yourself into a very tough frames.

What if, say, there is a situation where you come up with dictionary or errors? Or you'd need special response code to CarRequest? Or special response type like 'redirect'?

So - my suggestion is that you make a special kind of response per request until you find out some response similarities after significant amount of development.

There should be GetCarResponse to GetCar. Are you planning errors in response? Just throw an exception. Not found? Return null. Found? Return what you found and do not bother with errors.

Probably that requires a little more coding, but you have your hands free off some artificial limitations.