Comments on: Presentation Model: "Screen" Store Example

By: Colin Jack

Colin Jack — Mon, 19 Nov 2007 18:07:17 +0000

Ta for the example, someone really needs to write a codebase to make object to object mapping like this easy. I’m all for using TDD to develop the interfaces of the presentation DTOs but have Having to write the code/tests for the mapping by hand each time seems very painful. Did you ever look at using Spring, we’ve thought about it but we aren’t using presentation DTOs yet so there hasn’t been a big need:

http://forum.springframework.net/showthread.php?t=822

> the benefits of explicitly creating interfaces, even for domain objects

I find this thread useful when considering mocking the domain:

http://tech.groups.yahoo.com/group/domaindrivendesign/message/5683

Personally I don’t think I like mocking domain classes, especially not when it affects the design (e.g. requiring every class to support an interface or virtual members). Part of the problem, for me at least, is that if you scale this up any important abstractions are going to get lost in all the IFoo interfaces you include for mapping. Mind you when I do need a little mocking I turn to TypeMock anyway (guilty pleasure ).

By: BB

BB — Wed, 10 Oct 2007 17:04:00 +0000

Thanks for the clear answer! It helped me understand the reasoning behind the mocking of the domain objects. Looking forward to mentioned post!

By: joeyDotNet

joeyDotNet — Wed, 10 Oct 2007 15:54:31 +0000

@BB,
I have a post kinda in the works that explains some of the benefits of explicitly creating interfaces, even for domain objects (like the Monitor in the example).

The quick answer is that when possible, I like to encapsulate as much behavior and object interactions within the domain objects themselves. So if I’m writing a test for a service that has to perform some actions on a domain object, I don’t necessarily care *how* the domain object does what it does. I only care that the service is making the calls to the domain object.

The way all this relates is that if I was working with a concrete domain object, in which the behaviors might be complex (i.e. involving other objects, etc…), I may have to go through a possibly complex “set up” process to get the domain object in the needed state before it can be used in the service test. Patterns like ObjectMother and Builders can help with this and it is something I’m looking into.

But, in my service test, if I can just set up a couple expectations on my domain object’s interface, it removes the need for the service test to know *how* the domain object does anything and/or interacts with other domain objects.

Hope that somewhat answers your question for now.

By: BB

BB — Sat, 06 Oct 2007 08:01:25 +0000

Great post, and code example. I’m fairly new to mocking and therefore wondered what are the benefits of using mocking for creating the monitor objects in the test fixture? Wouldn’t it be simpler (and more readable) to just create the monitors using the domain class?

By: Jason Meridth

Jason Meridth — Tue, 02 Oct 2007 22:18:00 +0000

Count me in. I’m downloading now. Very cool post. Good idea to keep us active. Google Code rules!

By: joeyDotNet

joeyDotNet — Tue, 02 Oct 2007 21:29:00 +0000

Doh! Sorry about that. Thanks for setting me straight Ben.

By: Ben Scheirman

Ben Scheirman — Tue, 02 Oct 2007 21:16:31 +0000

Oops, It must be case sensitive or something I don’t know. Browsing the repository in googlecode shows it just fine.

For your readers, if you want to check out the code in SVN, here’s the command:

svn checkout http://joeydotnet.googlecode.com/svn/joeyDotNet/samples/Screen.Specific.DTOs/

By: Ben Scheirman

Ben Scheirman — Tue, 02 Oct 2007 21:14:16 +0000

Joey you rock. I’m downloading the code now and I’ll post my flames in a bit j/k

FYI: Googlecode’s svn link says http://joeydotnet.googlecode.com/svn/trunk but there is no “trunk” folder. I removed this and it worked.