Comments on: Code Review Quiz

By: Ryan means

Ryan means — Wed, 20 Jul 2011 20:32:00 +0000

Hello Chad,
I’m writing in the efforts of tring to find asp.net, c#, WPF deverloper for a client of mine in Austin. I’m here in Houston and normaly work on jobs in town.
If you or anyone you know may be looking please let me know.
Thanks,
Ryan Means
rmeans@vantageforce.com

By: Rich

Rich — Mon, 11 Jul 2011 21:09:00 +0000

The domain being modelled here seems very odd to me. I cannot think what business scenario would bank accounts, tranfers, products and customer photos would all be first-class aggregate roots within a single bounded context. It’s either a domain I am unfamiliar with or (more likely, given the extremely vague name), a thinly-veiled 90′s style DAL.

By: Peter Johanson

Peter Johanson — Mon, 11 Jul 2011 19:09:00 +0000

Yeah, I was wondering the same thing about the OrderDetails and CustomerPictures, whether they were true ARs or not.

By: Craig Cavalier

Craig Cavalier — Mon, 11 Jul 2011 19:05:00 +0000

Another issue with this interface is that it isn’t at all intention revealing, which of course, interfaces should be.If I were to hazard a guess at the reason for being of this interface, I would suggest that it only exists as a product of the EF tool, rather than there being a need for it (This suspicion was somewhat confirmed when I realized it was generated code).

Kinda seems silly now, picking apart the problems in generated code. Still a useful exercise in identifying code-smells mind you.

By: Craig Cavalier

Craig Cavalier — Mon, 11 Jul 2011 17:48:00 +0000

Interestingly enough, I managed to find
the IQueryableUnitOfWork interface – it was lerking in the namespace
Microsoft.Samples.NLayerApp.Infrastructure.Data.Core. Digging deeper still, implementers
of this interface also need to implement the underlying IUnitOfWork interface (which,
to my surprise is apparently part of the “core domain” – Microsoft.Samples.NLayerApp.Domain.Core)
and in turn,the ISQL interface (in the same namespace/project).

As you predicted, there’s a multitude of methods
here, including “commit”, “rollbackchanges”, “registerchanges”, “executequery”,
“executecommand”, and “createset”.

Let’s just say, I wouldn’t want to have to
implement this interface if I wasn’t using EF. To be honest, I wouldn’t
want to implement this interface regardless – we can do better. Of course, that
would make an interesting follow up post.

By: Nick

Nick — Mon, 11 Jul 2011 17:38:00 +0000

I think the use of properties could also be an issue here. Or maybe not. I’m expecting logic that can throw exceptions and have side effects by operating on those properties.

If I’m honest, I’d possibly do it the same way myself, though.

I think Ayende would disagree, and accept the use of IObjectContext. I could be wrong, but he doesn’t like data access abstraction and I think in his post he condones this behaviour.

I was expecting someone to chime in and say those entities aren’t aggregate roots, either. I would maybe expect order details to hang off orders, and customer pictures to hang off customers.

Please don’t shout if I’m wrong.

By: Chad Myers

Chad Myers — Mon, 11 Jul 2011 16:00:00 +0000

Good call on ISP. I had missed that one!

1 Derives from a big base interface (I guess this is the ISP issue)2 Regions!3 Exposes EF IObjectSet instead of IQueryable or IList4 OCP violation (have to add to it every time you add to the app)5 SRP violation (too much going on)
6 This interface, at least, is not a “unit of work” in the common definition of the pattern

By: Peter Johanson

Peter Johanson — Mon, 11 Jul 2011 15:47:00 +0000

The three major ones I spot right off the bat:

1) Violation of SRP.
2) Violation of ISP.
3) Returns the IObjectSet type everywhere, which leaks the details of EF into this “abstraction”.

Beyond that, this just “feels wrong” to me. Curious what specific issues others find that might help me understand the specifics of that “wrong feeling”.