Archive for September, 2008

DDD and Aggregates

Friday, September 26th, 2008

I started reading Eric Evans’ book Domain Driven Design.  (Seemed like one of those foundation books you have to have read if you want to be a certain type of developer)  I decided to give it a go after I got about halfway through the “Domain Driven Design Quickly” pdf – it seemed interesting enough that I wanted to have a go at the real thing.

Anyway, one thing it talks about is Aggregates… basically, a tree of dependent objects that don’t mean anything alone-like line items to an order, as opposed to a customer that is an entity that has meaning by itself.  I guess I haven’t explored things enough yet, but I’m thinking abouton something I’m looking at-I’ve got something like an order, and something like a line item.  There should be no separate repository for the line item.  However, in practice you may need to deal with the line item by itself, for instance the “edit the line item” screen on a website.  In a desktop app, you’d pull out the line item w/ roder, keep that around, and then save when the editing’s done.  However with this web scenatio, you come back from the editing screen and have… some IDs.  Sure, you may have selected the line item from the order… but as the web is stateless, you don’t have your order and order item all ready to update, you’ve got to rebuild that and apply the changes before a saving.  So, you’d pull out that line item from the repository *via the ID*. Or if you prefer, pull out the order via its ID, then iterate through its line items and pick out the relevant line item from the line item collection by ID.. also messy-you preserve the aggregate idea since there’s now no repository for  line items, but you’ve got iteration, and worse, a domain-level usage of picking by ID, which feels like bleed-through.  But you really need the order and the order item, so you can make your changes and then save.  Uh, I guess you can put them in your session, but that just seems even worse than either of the above options due to unreliability.  But maybe that’s me being pessemistic.  anyway, is there a clean way do deal with this?  Or at least a generally agreed-upon lesser evil?

Funny, apropos comic

Tuesday, September 23rd, 2008

Everything Is Going Just fine, thank you

KaizenConf, here I come!

Tuesday, September 16th, 2008

Woohoo! Just came back from lunch and my invite was waiting in my email!  I’m going to KaizenConf!  See you all in Austin!

List of Invitees
Interestingly, the list seems to be in first-name alpha order, so at the moment, I’m #1 on the list.  Wild.

Windsor, for real

Tuesday, September 16th, 2008

So, I finally got an implementation of an IoC Container (Castle Windsor) set up and being used in a production environment…. Based on the whole settings things up for mocking, it became very clear why they were needed!

On a current project, I’d set up and gone though writing tests as I went along.  It was a colleague’s task to write a bunch of integration tests.  (The question of how many full, top-to-bottom integration tests are actually needed is an interesting, but different question… regardless, they are well understood and trusted)  It turns out that all of these interfaces and the tons of newing up required for the dependency injection got to be pretty painful, and what’s worse, confusing and unclear.  Also, as I was refining things, I continued to refactor what was there, so the constructor signatures were changing… messing up AL those integration tests.  I think if he were less nice, he would have said “WHY do you have to make this so confusing??”

Exactly the situation IoC containers were made for.  And I think I got it all set up in about an hour, from download to finish!  Which is a few hours less than I’d expected.  I couldn’t quite get my create down to a single line a) because I was dealing with VB.Net, an irritatingly verbose, hard-to-scan language, but more importantly b) I had to pass in a configured object in to one of my objects, and then pass THAT on to the constructor of object I was really trying to get.  Previously, this chain was hidden among the plethora of newed-up stuff.  Once the container was in place, all I had were these special items, right after each other-this chain of dependencies on the configured object was very clear… the cluttering vanilla dependencies were out of sight.  I consider this a huge, and unexpected benefit.  If I need to change my constructors to break things up more (I have a few places in mind)  then I won’t break these complex integration tests.  My mocked out tests, sure… but they are each restricted in what they touch anyway, so the trouble there is much less.

I know, these were tests, and people often don’t use containers for tests.  However, because of their being integration tests, it felt appropriate.

An interesting point is that this is all going to end up being accessed through a single webservice, so the “live” newing up is only going to be in one place-so less *need* of a container for live.  This is just as well, because another team is doing the maintenance, and this way the unfamiliar stuff isn’t in actual live stuff that’ll could freak them out if something happens with it on live.  Same reason we went with VB…  Anyway, even if we don’t use it on “live” code, Windsor will still save us time.

Of note is really how all these things sort of come together as a package-  DI, mocking, IoC.  You want mocking, you do Dependency Injection, probably Constructor Injection.  You do much of that, and you’ll find yourself wanting something to magic everything up… thus your Inversion of Control Container.  I’d looked at containers a few months back (I’d heard them mentioned a LOT, and thought I should look into them), but I didn’t quite get a grasp of when or why you’d ever use them in practice.  I changed how I worked, and it became obvious.


Tuesday, September 9th, 2008

Attended an AlamoCoders meeting tonight.  Interesting talk on jQuery by John Teague. I’d previously seen Front-End Developers doing stuff with it, but I didn’t really “get” it-not that I’d looked into it, or tried… what with struggling to pick up nHibernate, DI, and that whole world of things, I felt like my plate was already pretty full.  This overview really helped though.  Previously, I’d glanced at a bunch orf jQuery code and just thought “uh, that’s not js…. not sure what this is. must look at-eventually”  turns out, the key things with jQuery are 1) philisophically jQuery is set up to work on elements much like CSS does.  it finds, groups, filters, etc upon the same IDs and element types that CSS does.  It looks a bit different, but much of jQuery stuff is really just finding elements, picking out selectors, etc.  2) jQuery is sort of like working at the UNIX command line-it’s all about feeding the results of one thing to the other… jQuery code is chains of long commands that find, filter, and then do something (like assign a function to a click action)  this code is short, and once you get the hang of it, easy to read.  As a side benefit, it even keeps code out of the HTML.. not even any “onClick” commands.  Nice.  doing *that* without a library is not fun at all.

As an aside, I won a copy of “LINQ Unleashed”.  I confess the actual naming of the “Unleashed” titles amuses me.  It seems one step short of a wacky reality show title… imagine, “When SQL Attacks” or “Mocks Gone Wild” ..I mean really… eh… no looking a gift book in the mouth, I guess.

Tried for a spot at KaizenConf (Kaizen, as in a Japanese word for Continuous Improvement, it seems)… it sounds like a great learning experience, and it’s practically down the street in Texas-terms.  Sounds like it’s not a direct registration process, but some sort of judgment-on-mystery-criteria-then-invite.  That’s a bit discomfiting, but hopefully it’ll work out.

Moq and mocking on a real project

Tuesday, September 9th, 2008

So, back to blogging… (the whole moving, changing jobs, losing boxes, and generally throwing my life in disarry made expounding on topics an admittedly lesser priority)  in the past week or so, I’ve looked into Moq, mostly on the basis of it being the newer, cleaner, super-awesome mocking framework.  I’d played with Rhino Mocks in the past, so I did have some baseline for comparison.  However, in this case, time and ease was of the essence-I was using this on a real project in which nobody else knew mocking, so quick rampup and ease of explainability were key. Maybe not the best time to pick up an unfamiliar tool, but… uh, no time  like the present and all, I suppose.  I figured since a testing framework is only used on the test side and the production code is not dependent on it (please, don’t split hairs about testing code being production code, I know it sort of is, but that’s not the way I mean) that the risk was a manageable level.  I went out, and set up tests using mocking for all repositories, and for internal utilities.

Moq sure is different from Rhino Mocks.  The basic idea of mock as stub-type thing is preserved, but the actual usage is very different.  In Rhino Mocks, you declare a repository for the mocking framework, get an object from it that fits your interface, and then record a bunch of calls onto it.  Later, you set the mode to play, then run your test code.  Finally, you can verify that all the calls you set up were actually used.  This record/play model takes a bit of time to understand, and to see what it’s for.  In contrast, Moq does away with the special mocking repository, and the who record/replay stuff.  Sounds really easy, right?  Not so fast.  Moq uses lambdas/delegates to set up the calls on the mock object.  Lampdas are a pretty new feature, (thus still new to a lot of people)  and one of the less-easiliy-readable-to-a-newbie- features I’ve come across in .Net.  I’d say they’re up there with regular expressions in terms of initial incomprehensibility.  Worse, I am restricted to implementing using VB.Net on this particular project.  If you thought lambdas were weird with C#, they’re even worse in VB.  I’m a bit worried that I may have introduced a *big scary* thing into this project with using these VB lambdas.  We’ll see if I’ve shot myself in the foot or not here.

Another item of note about this is that is is actually the first time I’ve used mocks in a real project and not just toy projects at home….(old projects sans interfaces could probably be TypeMocked, but not regular mocked without a whole lot of destruction)  It changes the whole project, pushes into the dare I say “modern” way of developing.  This project is essentially greenfield, so there was some oportunity to set things up the way I needed.  This may be obvious, but interfaces really are key.  You use an interface, you can mock.  No interface… well, it’s going to be a whole lot tougher.   The other thing, you have to be able to inject your mocks to use them instead of the regular classes. So… poof, project gets DI.  Once you’ve got things heading that way, your constructors explode.  I have the feeling I’m going to get some pushback on those.  So, if your repositories are mocked, and various utilities are mocked, you end up with a constructor with 8 things in it, and some of those have constructors with a bunch of things… yow!  Which brings in (hopefull) an IOC container to manage the madness.  It’s a waterfall of cause/effect.  Is all that worth it?  Well, you get a lot more flexibility and significantly more granularity in testability.   But what if 95% of developers have no clue about IOC/mocks/DI- these concepts are not only somewhat unknown/advanced, but are genuinely tough to wrap your head around-you’ve just wounded your maintainability through no fault of the technology itself.  Still worth it?  I can’t really say.