Comments for paulpierce.co.uk

Comment on First try of NMock2 by Paul Kinlan

Paul Kinlan — Wed, 21 Mar 2007 12:19:37 +0000

Every NMock 2 search I do comes up with this, lucky really because I need to do indexers in NMock2.

Comment on Soap Headers in WCF, where have they gone. by Paul Pierce

Paul Pierce — Wed, 07 Mar 2007 17:17:36 +0000

Alright Paul,

Thanks for the comment, makes a change to get one thats not spam.

I can see the benefit of the contract first approach, in that the wsdl’s produced are more human readable and give you a more control over validation etc. The code first approach isn’t the right choice for all applications and I agree that an initial investment of time in writing the wsdl could save time in the long run.

But i disagree with “Messages are not objects, and they should not be thought of as objects”. Surely your wsdl will ultimately be used to generate a Data Transfer Object of some kind, so why not think in terms of the DTO to start with?

I will have a look at the webservice software factory.

ps. Enjoyed your posts on Devweek

http://www.kinlan.co.uk/2007/02/day-1-of-devweek-conference.html
http://www.kinlan.co.uk/2007/03/devweek-day-2.html
http://www.kinlan.co.uk/2007/03/devweek-day-3-review.html

Sounded like it was really interesting, Maybe next year :).

Comment on Soap Headers in WCF, where have they gone. by Paul Kinlan

Paul Kinlan — Wed, 07 Mar 2007 15:55:28 +0000

“I personally prefer the Code first approach and find it much easier to think of messages in terms of objects”

Messages are not objects, and they should not be thought of as objects. Messages are messages that contain data. The good thing about contract first is that you define up-front a schema (noramlly wsdl/xsd) that everyone can conform towards.

I belive the Webservice Software Factory has some guidance and help around headers. It is on Codeplex under patterns & practices.

Paul Kinlan

Comment on First try of NMock2 by dibbin

dibbin — Fri, 07 Jul 2006 20:23:37 +0000

Thanks for being the first none spam comment on my blog.

The stub data reader in the article you mentioned, provides an good way replacing your db for testing and depending on the circumstances, may be more suitable than using NMock, especially if you wanted a more generic solution.

The article also highlights some of the benefits of using NMock: Without NMock we would have to build stubs in a similar way to the StubDataReader implementing all members; you can see by comparing the amount of code above to the StubDataReader that this is a considerable time saving. NMock also allows us to say exactly how an object will be used, what properties/methods will be called, how many times etc.

Comment on First try of NMock2 by Paul Kinlan

Paul Kinlan — Wed, 28 Jun 2006 14:50:09 +0000

Would it not be simpler and more reusable to create a Stub DataReader and Stub Record Collection that could fake the results from the DB, so that you can check the data parsing works correctly.

Much like: http://www.haacked.com/archive/2006/05/31/UnitTestingDataAccessCodeWithTheStubDataReader.aspx