Let’s evangelize good architecture, everyone!

February 26th, 2008

Yeah, and by that I mean that you shouldn’t publish bad code. And if you do, dont forget to mention that this is just example code, and you’d do it differently in a real world app.

Not following? Let’s get practical:

[ControllerAction]
public void Find(string query, string format)
{ 
     var flickr = new Flickr(ConfigurationManager.AppSettings["flickr.api.key"]);
     var photos = flickr.PhotosSearch(query, TagMode.AnyTag, query, 40, 1);

     ViewData["query"] = query;
     ViewData["photos"] = photos;

     RenderView("results");
}

Nothing wrong with this code? Easily testable? No tight coupled dependencies? How would you test it?

Categories: General | Top Of Page | 25 Comments » |

25 Responses to “Let’s evangelize good architecture, everyone!”

Mike Says:

I’m guessing that we should inject the Flickr into the controller through a constructor… otherwise the only way to test the controller is to test the controller AND the web service call. I would want to test those two aspects separately :) But hey… that’s just me.

Rob Says:

Impossible to test. You need some sort of IPhotoRepository injected rather than using Flickr directly. At least, that’s what I would do, but what do I know…

Tuna Toksoz Says:

I agree with Mike. And I don’t like using ConfigurationManager.AppSettings["flickr.api.key"]) and i prefer injecting it, but this may be considered as something personal.

Victor Kornov Says:

This is perfectly good for “some quick example code, that I quickly through together” :) Sorry, I just don’t like “quick” posts.

I personally have smth. like IFlickrSettings and IFlickrSearch[Adapter] in such cases.

Tuna Toksoz Says:

Yeah, and after reading rob’s, I couldn’t agree more. It is a bad practice to use provided api directly. It would be better to use it in some other layer/service and consume it in the controller. It doesn’t always have to be flickr, but maybe google photo share(picasa?) so i’d go that way, too.

Hüseyin Tüfekçilerli Says:
Justice~! Says:

Gee, I wonder if this has anything to do with our earlier discussion!

This was my point to you earlier. Admittedly, I probably would’ve used some tact to, you know, E-mail Ben privately to say this wasn’t the best example for people and to offer some suggestions for improving it for other people.

Obviously, I’m not a fan of putting in sample code that isn’t a good example for people to learn from, so I’m glad you are trying to hold Ben accountable. From what I know of him, he would welcome your feedback.

Ben Scheirman Says:

The point of that post was to show how javascript can be used to hijack a form submission and use ajax instead.

Anyway, I see your point in that I should advocate more rigidly the importance of testability and inversion of control. In fact, I think the server action should look more like this:

var photos = /* get photos from somewhere */

which would not detract your attention from the intent of the post. I wrongly made the assumption that 99% of my readers know & understand how to decouple their apps & make them testable. Shame on me :)

Tuna Toksoz Says:

Hammett, could you write more about testing? I mean, somee challanges that you faced, or some unordinary cases. It would be great. What do you think?

Bruno Fiorentino Says:

Good.
Could you write about challenges about interaction based tests and mock objects?

Tks.

Bruno Fiorentino Says:

Our team is building a MVC Web Application with MonoRail and all the components (DataMappers, Repositories and Services – PEAA) are created as plugins(Separated Interface – PEAA) on Windsor Container.

We have small(and focused — good Separation Of Concerns) classes and methods but we aren´t doing TDD. We´ll create the unit tests later because, unfortunately, not all the team members are familiarized with Unit Tests at the moment.

I´m proficient with C#( and OO) and reading about TDD, but some members are have an ASP/VBScript background, so TDD is a good path now.

The hardest Unit Test topic for newcomers, in my opinion, is ‘Interection Based Tests’.

Any advice about ‘Intection Based Tests’ will be usefull.

Tks.

Bruno Fiorentino Says:

SORRY the sloopy english!

(ERRATA in UPPERCASE)

Our team is building a MVC Web Application with MonoRail and all the components (DataMappers, Repositories and Services – PEAA) are created as plugins(Separated Interface – PEAA) on Windsor Container.

We have small(and focused — good Separation Of Concerns) classes and methods but we aren´t doing TDD. We´ll create the unit tests later because, unfortunately, not all the team members are familiarized with Unit Tests at the moment.

I´m proficient with C#( and OO) and reading about TDD, but some members HAVE an ASP/VBScript background, so TDD ISN´T a good path now.

The hardest Unit Test topic for newcomers, in my opinion, is ‘InterAction Based Tests’.

Any advice about ‘InteRAction Based Tests’ will be usefull.

Tks.

Joe Says:

Why the antagonism towards Palermo and Ben? Did you want in on their book project?

hammett Says:

There’s no antagonism here. I was just called out for not helping the community.

Tim Says:

You know this is the kind of post that bothers me a bit and I hope you (hammett) or other will address.

The problem is the code above looks like something I would write. I’ve read books on TDD, I read blog after blog and article after article about decoupling and testability, and yet, I would write the code above. Am I stupid? A poor learner?

There are a few voices out there that are loud and proclaim these thing and us blog readers out here are lapping it up like a ravenous dogs, however when push comes to shove and we have to code our own applications we’ve got no guidance other than some words on a blog post about “decoupling”.

I think this is evidenced well by your first three comments above, you posted a small code blocked and yet the first three commenters offered up their comments along with the caveats, “but hey..that’s just me”, “At least, that’s what I would do, but what do I know…”, and “but this may be considered as something personal.”

In other words, I will paraphrase as “I think I know the answer but I wouldn’t stake anything of value on it”

That’s just it, no one knows and the few people who do know keep talking about things they think everyone should know.

We, the community of journeyman programmers, need some solid resources to go learn this stuff. Do you have some? Anyone?

Jeffrey Palermo Says:

@hammett,
>I was just called out for not helping the community.

I think I’m missing some context. When were you called out and who did it? It seems to me that you help the developer community quite a bit through the Castle project.

hammett Says:

Wasn’t you, Jeffrey.

Tim, have you read http://www.codeproject.com/KB/architecture/introducingcastle.aspx ? What else are you looking for? Books, articles?

Tim Says:

@Hammett

I have not read that particular article but have just printed it. However I have read a number of articles/blogs from codebetter guys (Palermo, Seguin, ect) and have read much, if not all, of Martin Fowler, along with many many other articles.

> What else are you looking for? Book, articles?

I’m looking for anything else that would help me become a better developer. You referenced one article on codeproject’s website. Last I looked the internet is a big place. If I were to come across that article how would I know it’s trustworthiness? I’ve found many bad articles on codebetter, so if I were to happen upon the one you pointed to I could just as easily be learning/digesting bad information as good.

We, out here trying to learn this stuff, need a siphon/mentor telling us which are the good articles and which are the bad. Books are helpful too! Podcasts! Videos! Anything!

Tim

hammett Says:

I dont think such thing exist. At some point you’re going to develop your sense of what’s right and wrong, your bias towards articles and authors. There are no shortcuts. It’s all part of learning and getting better everyday, and it does take years.

An exercise I often do is remembering the projects I’ve been involved, and how I’d approach them differently, what I’ve done wrong, what was nice and I should use more often.

Tim Says:

@Hammett

Seems to me then there is a danger you will have developers never really knowing that their doing something correctly. Granted, “correctly” changes as technique evolves, but the very code above that you are saying has something wrong with it, might be considered “good” by another developer, maybe the developer who wrote it “sensed it was good”.

The other point I want to address is the first three comments and how they didn’t seem to sure of themselves. I resonate with that sentiment, I constantly ask myself, “are the things I’m doing correct or right.” Maybe that’s all that’s required, introspection, but I do feel there is a communal need out there right now for some concreteness.

Tim

P.S. Going through your article now and I like it, however where is part III?

hammett Says:

Tim, the best way (I dare to say the only way) to resolve this dilemma is joining a company with great people. Get someone to review your code and review their code. Learn from them, discuss design decision, code decision, even the small things. I’ve been luck enough to work at one of best brazilian’s software company, which changed my perception of code, quality and values.

Trying to learn all that by yourself is not impossible, but I know wont be easy. No books, blogs or articles can replace an one-to-one talk.

Tim Says:

@Hammett

At our place of work, I am that guy. I teach, evangelize, train, ect. Typically when I write something “good” many of our juniors are confused by it. We have people who truly care about their work, but they are echoing my sentiments…

The answer can’t only be find a better set of people to work with, that would provide too bleak of an outlook.

Tim

Darius Damalakas Says:

@Bruno Fiorentino,
it’s better to have some tests, thad to not have at all.

I started digging into unit tests last spring, it is still hard to write good tests, but the result we get from tests paid many times the effort we spent on writing them.

First, it changes your thinking(!), second, you when something breakes. Do it in small steps and eventually everybody will follow this practice

Bruno Fiorentino Says:

@Darius Damalakas

HI, thanks for your advices.

I´m looking for this advantages, and will do this tests in a way or another bit I have some specifics “dilemmas”:

My app has a repositorie´s layer that “talks” to a dataMapper´s layer. Repositories and dataMappers are components registered on Windsor Container.

The project will be released with a set of “SQL SERVER dataMappers”. The second release will offer a set of “Lucene DataMappers”, tha can (optionally, via windsor config) replace the SQL Server DataMappers for an “app instance” (something like a SaaS implementation).

*** I am looking for the best approach to test this layers:

I) Just write interaction based tests between repositories and mocked dataMappers.
II) write interaction based tests between repositories and mocked dataMappers AND assert based tests for both “SQLServerDataMappers” and “LuceneDataMappers”.
III) ??

Have you faced something like this?
What do you think (or would you do)?

Thanks!

Bruno Fiorentino Says:

Leave a Reply