I'm working on a chapter on layering for the upcoming Brownfield book, and for better or for worse, we're including a section on the onion architecture. I've heard the term mentioned for some time now but for the life of me, I can find only one meaty series of posts on it in recent months. That one caused a bit of a kerfuffle but the ado was big enough that I said to myself, "hillbilly, you don't want to be treadin' into dem waters anytime soon." But I need some excuse to do some extemporizin' and I'm hoping this will help crystallize things in my head.

I'll start with my own version of the diagram because I spent enough &*%$ time on the thing. Wanna get some mileage out of it.

Jeff's explained it pretty well, I think. It's clear that the Domain is at the centre and thus, is the focus of the application. I've skipped the Domain Service layer for two reasons:

• It should be part of the Domain layer
• There's a good chance that your domain services should really be methods on your domain objects. (e.g. FundsTransferService should really be a TransferFundsTo method on the Account object)

So here's where my take comes in. I don't like the onion metaphor, or the diagram a whole lot. For someone coming at it from a traditional n-tier approach, it's confusing. It looks to me like the UI talks to Application Services, which talks to the Domain. That is, it's not obvious that the outside layers can talk to any inside layer without some fancy footnotin'.

The problem I think is with the term "layer". It implies a level of insulation. That is, the Domain looks like it is insulated from the UI and Infrastructure by the Application Services layer. Which isn't the case by any stretch.

Next issue is that the diagram does *not* make clear what was a hard concept for me to understand initially. Namely, that the interfaces for the repositories live in the domain but the implementations in the infrastructure. And it's done without the UI referencing the infrastructure layer (usually with an IoC container).

Then there's the whole UI segment abutting against the infrastructure which is kinda wacky. Can the UI talk to the Infrastructure? Does the Infrastructure even use the Application Services? In my experience, not really. It interacts directly with the Domain.

Which brings up another issue. How does the use of DTOs affect this diagram? I'm on the fence about this, but I've seen cases where the UI doesn't ever use domain objects. The objects are translated into DTOs by the Application Services. So the UI "layer" doesn't technically have access to the Domain "layer".

Having said that, I don't know if I could come up with a better diagram. As it is, I don't know if I could even properly define "Application Services". All I know is that, for someone relatively new to this, an analogy should not need three posts to explain it.

When Jeff's posts came up, I read them with interest and they jibed with my understanding of onions in general, so I moved on. The metaphor seemed natural but I admit, I didn't look into its meaning too much. Hillbillies aren't a naturally metaphorical species.

Now I'm having to dive into it a little more and I find myself wondering if it will do more harm than good. To the inexperienced, it looks like a vastly different take on the traditional n-tier diagram. And on more than one occasion, it occurred to me that they aren't really that different. To oversimplify, you could just substitute the domain layer for the business logic layer, change the direction of some arrows, and have a passable draft of it.

On the other hand, this line of thinking does *not* bode well for me finishing chapter 8 this weekend.

Kyle the Indecisive

The first alt.net Canada conference is come and gone and as Doc went through the rules of engagement for Open Spaces on Friday evening, the one that stuck out for me this time was "Whatever happens is the only thing that could have".

As he listed it, I couldn't help thinking of State and Main, written by my favorite screenwriter, David Mamet. In it, the star of the movie they are shooting, played by Alec Baldwin, gets into a spectacular car crash (no wait, that's not the analogy I was thinking of). He walks away unscathed, looks around, and says quietly to himself, "So...that happened."

It's the way he says it so blithely that triggered the memory during alt.net. He says it as if it is the only thing that possibly could have happened. Which is the essence of principle three of Open Spaces. And it would be an awesome quote to start the retrospective had I been more on the ball.

I don't have a decent segue into the real point of this post but I love working movies into my posts, especially ones by David Mamet.

The event was, in my humbilly opinion, better than I hoped it would be. Which shouldn't have happened had I heeded Doc's advice to "be prepared to be surprised" but there it is nonetheless. A good turnout. Minimal logistic issues, thanks to a very good-natured group. Bil Simser has done a pretty phenomenal job so far videographing the event. Here is my brief take on some of the talks I attended:

Which presentation technology should you use?
It depends

Telecommuniting, or "Don't you hate pants?"
This was a topic after my own heart but I have more to say on it than I can cover here. Coming soon...

Command/Query Separation and Occasionally connected applications
I blipped back and forth 'twixt these two because they were similar...yet different. Seems to me that command/query separation would be a good way to build an occasionally-connected app. Tucked a bit of info away for the day when I eventually need to build one.

Volunteering our skills to more than just OSS
Convened by Donald Belcham and one of my favorite topics of the conference, primarily because it is the epitome of what I love about this event. You'll never see a similar topic discussed at your average code camp or likely even at a major conference. In it, we talked about projects people have done to benefit the community at large, not just other developers and we talked about how to volunteer for similar projects. I'm hoping details will be forthcoming on the Proceedings page but if they aren't in a few days, I'll elaborate.

Convention over configuration
Discussed existing uses of the principle in things like StructureMap and NHibernate, as well as recent implementations of it in MVC and Fluent NHibernate. Also talked about potential pitfalls, when its appropriate, and how convention compares with tooling. Again, I can elaborate if there is interest.

How do you choose the right framework?
There was just a little too much focus on "What is Microsoft doing wrong?" that I made some attempts to steer people away from but all in all, I got my questions answered. The answer to the title question I gathered was "hone your instincts and use them."

As I mentioned in the wrap-up, my major goal was to re-connect with old friends and start making new ones. I find the social aspect of alt.net to be the most beneficial as it fits well with the nature of Open Spaces. Despite my closing remarks, there almost certainly *will* be another event and discussions have already begun on possible locations and dates. And early indications are very positive.

Thanks all for a great weekend and especially to Doc for facilitating both the event and the conversation on the way back to the hotel Saturday night with Lyle and Osie (and I sure hope I spelled your name reasonably).

Kyle the Alternative

In my penultimate post, there was a comment from Chris that I purposely didn't include in the follow up:

It's amazing how many ASP.NET "Web Developers" don't know anything ,or very little anyway, about html and javascript.

My response to this is a little more involved to be included in a compendium. I know I said I was trying beligerence on for size but I want to backpedal. Yes, many web developers prefer to work in the designer and may not know HTML and Javascript inside and out. The point of the post was to encourage people to try MVC out. And to encourage them not to shy away from having to do a little more work yourself (vis-a-vis HTML and server-side controls).

But in my condescension, I worry that I may have scared people into thinking "Well, he's a big, bad web developer with too much time on his hands. I don't have the time or the wherewithal to learn both this framework and everything else needed to make it work." Furthermore, I keep getting a sense that people are afraid to ask questions because of some inate fear of being thought an idiot. I think it has to do with the way we throw around goofy terms as if they are common knowledge.

In Twitter one day, I threw out the idea that my bio for all future presentations will be: "Kyle is just a guy." It was after reading the one I submitted for a presentation and thinking, does anyone really care about what I've done in the last x years? And if they are, wouldn't Google give them a better idea of who I am than I could when I'm in marketing mode?

Following that train of thought, I eventually got to thinking that these trumped-up bios are actually detrimental. After having that thought, I started reading between the lines of my bio: "Kyle is a guy with ten-odd years experience in a ton of different technologies so he is able to figure out all these high-falutin' technologies like HTML and CSS at a glance and he's willing to impart various pearls of wisdom to you because he doesn't think you can do it on your own."

Well, here's the thing: I *am* just a guy. I figure this &*%$ out the same way you do. By reading blogs, watching screencasts, and diving in. The difference may be that I ramble about it more than you might. And in those ramblings, you are reading more about my successes than my failures and roadblocks. So it may sound like I just decided to sit down one day and learn MVC and lo! out shat a blog post. (Sorry for the crassness. I'd edit it out but I'm killing myself laughing re-reading it.)

I learned MVC by reading blogs from the team that built it and by stumbling through Google and by building an app with it. I also have a cadre of people on IM or e-mail that are crazy-friendly about answering questions. Along the way, I was also fumbling through NHibernate, IoC, and architecture in general. It took (and is still taking) quite a while and I was "lucky" enough to be between contracts at the time so yes, I admittedly did have too much time on my hands at the time.

Despite my recent lapse, it doesn't do any good to add to a person's fear that they are being left behind with all these new-fangled frameworks. Taking the high road and saying "Learn HTML, you unwashed heathens" is not going to endear you to anyone, let alone the unwashed heathens (I'm kidding, back away from the comment button). A better way of saying it may be: "Yes, server-side controls likely won't work the way you want them to in MVC. But I've had lots of success sticking with basic HTML and managing the view state myself. It's not nearly as hard as I thought it would be."

Now, I'd probably spice that up a bit so that it didn't read like it had been washed through an affirmative action machine. But at least it doesn't raise feelings of "Ya, Baley's off his porch if he thinks I'm going to learn MVC *and* Javascript just so he can add to his superiority complex." What you get along with unspoken feelings of animosity is people who will just silently tune you out.

Kyle the Ameliorated

Some pretty good comments in my most recent post on (re-)learning HTML in order to work with MVC. A few worth expanding upon.

Will Shaver says:

Actually... I'd counter that Javascript is the hardest tool in the box to use correctly. Harder than c#, sql, asp.net, webforms, html etc. It has several KEY differences to all other object oriented languages in the standard toolbox. Prototypal inheritance, functions are objects, objects are containers.

Even worse is the massive amount of BAD information out there for javascript. For example the || is the "default" operator and has different meanings in Javascript than in c#!

For more, read your crockford....

The Hillbilly says:

Yeah, I did kind of gloss over the intricacies of Javascript. If you use it to its full capacity, it can be pretty tough to understand. I have only vague notions of its inheritance mechanism. But the Javascript libraries available today make it easy to use without having to delve crazy deep into the more advanced concepts. I'm dancing around the line between encouraging you to look into its inner workings and encouraging you to use a library so you don't have to. Not sure where the trade-off is because I don't think I've found it yet. But Javascript still isn't too bad.

Helen says:

For me the lack of server controls is a big reason that MVC doesn't look too appealing to me because they're a big help in reusing repeated elements on different pages. WebForms is definitely a framework that's showing it's age but I kind of feel like Microsoft threw the baby out with the bath water when they designed MVC.

The Hillbilly says:

To be clear, and you probably already know this, WebForms isn't going away by any stretch. And MVC is not the next evolution of WebForms. It's a framework for building apps on the web, just like WebForms is.

But the nature of MVC as it applies to the web is such that server controls don't make a whole lot of sense. Server controls are all about managing state. The web is stateless. MVC doesn't throw away server controls. It just doesn't accommodate them because of environmental restrictions.

Also, user controls are still supported in MVC, though again, you can't really use server controls in them. Only standard HTML elements. Which means you need to manage the state yourself. And in my experience, that's a good thing because user controls are traditionally where I've had to become, shall we say, "familiar" with the ASP.NET life cycle.

Łukasz Podolak says:

Could you explain :

"Or at the very least, that it's never been easier to add rounded corners to a DIV." ?

The Hillbilly says:

I was being flippant actually but just the same, I haven't had too much trouble. I'm using jQuery and this plug-in. I did have a problem with it working in IE because it uses excanvas which apparently IE doesn't support natively. But this library helped solve that issue. There are other plug-ins for jQuery and I'm sure you've tried some non-jQuery ones but I like this one because it doesn't add a bunch of nested DIVs to your elements to achieve roundedness.

Charlie Barker says:

The problem they have failed to come up with a solution for (as far as i know) is the 3rd party controls issue. 3rd party control developers need a way to plug their controls into the MVC framework. Without this small in-house dev teams that rely heavily on these controls will have to stick with webforms.

The Hillbilly says:

That question came up as well. As yet, I haven't found any companies offering third-party controls though I admit I haven't looked too hard. It'll be interesting to see what comes out because they'll be "limited" to what can be done in HTML. I don't foresee this being a big deal though because everything that's possible in WebForms should be possible in regular HTML, mostly because WebForms controls *are* HTML when you get right down to it. Besides which many of the vendors already offer AJAX versions of their controls. It will be a matter of getting their hands dirty and scaling back to the basics.

Keep the comments coming. This was one of the easier blog posts to write.

Kyle the Verbal

Presented last week at the Calgary .NET User Group and the Edmonton .NET User Group. Both went swimmingly in this hillbilly's view and I had a fantastic time doing both. At some point, I'm going to have to admit to myself that I probably do this for my benefit more than the attendees. But as long as both our interests align, I'll keep telling myself I do it to help the community.

As a bonus, I get this nice shiny blog post out of it. Because the same question came up at both meetings and I didn't give it its due either time. The question was, and I'm paraphrasing:

I'm diggin' the new framework and all and your love of plaid is refreshing, but I'm a WebForms guy. This new-fangled way of putting these "INPUT" controls on a page is strange and unfamiliar, but not in a good way. You're asking me to abandon all I know of web development. My asp:ListBox? My asp:DropDownList?!? FOR THE LOVE OF ALL THAT IS HILLBILLY, DON'T MAKE ME GIVE UP MY PRECIOUS GRIDVIEW!!

The response I gave to this question in Edmonton was: We're web developers. Learn HTML.

I was about to say that this probably sounds more condescending than I meant it to be but I don't think that's true. Subconsciously, that's kind of what I think whenever I'm asked. Usually I sugarcoat it but I'm testing the waters into beligerence these days to see where it takes me. So far, I don't think I have the stomach for it but I'll give it a couple more weeks.

Anyway, as much as Microsoft has gone to great lengths to protect us from the scary world of HTML, let's not forget that the web is still very much powered by it. It behooves us to learn it (and I'm not using the Webster definition of "behooves", not the one I learned from my sister-cousin).

Here's the thing: HTML is not hard. Javascript is not hard. HTTP is not hard. Statelessness is not hard. In general, WebForms is an abstraction over a problem that is not hard. Especially now that we have some pretty mature Javascript libraries, like jQuery and Prototype. And certainly now that pretty much any problem you might encounter related to managing statelessness has already been solved several times over.

Web applications have become pretty sophisticated over the years such that users are starting to demand more for their "money". It is my experience that the demands they are making do not play nice with server-side controls. WebForms was a nice model back when it was acceptable to perform a full-on postback every time you wanted to go to the next page in a grid.

But this is 2008. And I'd like to be able to bookmark that page now and e-mail the link to someone else. I'd like the ability to click the Back button and not get a Page Expired error. I'd like to sort a list of items and not have it add to my browser history.

You can do all this in WebForms, of course. But usually, people say it like this: "Well, that's possible in WebForms...." Not "Dude, that's a freakin' BREEZE in WebForms. It was designed with that specific scenario in mind."

So yes, if you're interested in MVC, you'll need to know a bit about HTML. You'll need to manage any "state" yourself. You'll need to understand what happens when a form is submitted via POST vs. GET. You'll need to account for things like validation during a form submittal.

But don't shy away from it. Give it a try, it's not hard. The <INPUT> tag has its flaws but it's pretty simple to figure out. Maybe take a Javascript library out for a spin. You might even find that it's fun.

Or at the very least, that it's never been easier to add rounded corners to a DIV.

Kyle the Web-Formed

PS. Code from the presentation will be forthcoming.