Design and Architecture

It’s all about the delivery

Hadi Hariri — Thu, 29 Oct 2009 20:32:37 GMT

The Dependency Inversion Principle states:

A. High-level modules should not depend on low-level modules. Both should depend on abstractions.

B. Abstractions should not depend upon details. Details should depend upon abstractions.

(Source WikiPedia).

Throw that at a terrible programmer, and all you’ll get is a terrible programmer that is annoyed and hates you. So true!

Take the following method:

        public void PrintHelloMessage()

            Console.WriteLine("Hello");

Now ask a developer to add a new method to print the message ‘Goodbye’. Do you think he would do:

        public void PrintGoodbyeMessage()
        {
            Console.WriteLine("Goodbye");
        }

or:

        public void PrintMessage(string message)
        {
            Console.WriteLine(message);
        }

Most likely, he’d do the latter. Why? Because he realizes he’s gaining a benefit by passing a parameter to a method. He knows that if tomorrow you ask him for a “Good Afternoon” message, he won’t have to write a new method.

What is Dependency Injection? It’s one way of complying with the Dependency Inversion Principle. However, when you think about it, what does it boil down to? Passing a parameter to a method, which happens to be a constructor. It seems simple enough doesn’t it? Yet, it’s hard for people to understand it. Why? because they don’t see the value in it.

Explaining a principle to someone without them understanding the benefits and values they get out of it is useless, and that is why concepts such as Dependency Injection or Inversion of Control seem overly complex to the vast majority of developers (believe it or not, those of us that use these things are still a very big minority). It’s complex because they haven’t been explained the values of it. They’ve just been thrown some definition and they are expected to understand that it’s bad for one class to create an instance of another class it uses.

Present a developer with the following code:

    public class AuthServices

        public void AuthUser(string username, string password)

            var authDAL = new AuthDAL();

            var user = authDAL.GetUserByUsername(username);

            if (user != null)

                if ...

and ask them how they’d go about testing this code without having access to a database. Ask them how they’d go about changing AuthDAL for some fake DAL that doesn’t really connect to a database.

They’ll probably come up with the solution of passing the AuthDAL class in as a parameter, and eventually realizing that multiple methods will use the same class, they’ll pass it in via the constructor and set it as an instance field. As long as their AuthDAL has virtual methods, they can create any fake DAL that overrides those methods and returns some dummy value. They might argue that they don’t want virtual methods. And that’s fine. Tell them to define the parameter as an interface. In fact, they probably have already heard of a principle that says that you should program to an interface and not a class. They’ll eventually end up with this code:

  public class AuthServices
    {
        IAuthDAL authDAL;

        public AuthServices(IAuthDAL authDAL)
        {
            _authDAL = authDAL;
        }

        public void AuthUser(string username, string password)
        {
            var user = _authDAL.GetUserByUsername(username);

            if (user != null)
            {
                if ...
            }

        }
    }

And voila! You have Dependency Injection via Constructor.

Once they *get* that, then explain to them other benefits, you know the real benefits they get from doing this: decoupled code, easy maintenance, promotion of SRP, etc. and then throw the principle in their face:

A. High-level modules should not depend on low-level modules. Both should depend on abstractions.

B. Abstractions should not depend upon details. Details should depend upon abstractions.

And they’ll see how it all makes sense.

It’s not about throwing or not throwing books. It’s about showing people how something can help them, how they get value of it.

Upcoming talks

Hadi Hariri — Wed, 09 Sep 2009 12:29:56 GMT

Start of the “conference season” again and I’ll be doing a tour of a few countries and places. Hope to meet up with some of you at some place and time. This time I’ll try and have all sessions ready so I can spend my time more productively at the bar/restaurant

- 21st to 25th September at BASTA! in Germany. Talks on ASP.NET MVC, jQuery, TDD, Design Principles.

- 27th to 30th September at Entwickler Konferenz in Germany. Talks on ASP.NET MVC, TDD.

- 12th to 13th October at DevReach in Bulgaria. Talks on ASP.NET MVC, Design Principles.

- 16th to 17th October at TTT/CodeCamp in Tarragona. Talks on MEF and Design Principles.

- 18th to 21st October at SDC in The Netherlands. Talks on ASP.NET MVC.

- 29th October at Micrsoft in Madrid. Workshop on Design Principles (Link available soon)

I’ve also pre-recorded 3 sessions for an online virtual conference on ASP.NET MVC, jQuery and Mocks, all in Delphi Prism and it’s happening right now on CodeRage

ASP.NET MVC "Models": The lonesome folder!

Hadi Hariri — Thu, 07 May 2009 08:18:14 GMT

ASP.NET MVC comes with a Models folder but no Model. Although some see this as a shortcoming, I'm actually delighted that the framework does not bind me to a specific data technology or pattern. If I want to use Active Record I can use Castle's ActiveRecord. If I want to use a Repository Pattern, I can use NHibernate. If I want to throw something together for a quick prototype, I can use Linq 2 Sql. The advantage of not being tied to a specific data access pattern for me is a win situation.

In many a demo, it's been indicated that the "Models" folder contains your model, whatever that happens to be. It could be your Domain Model, your L2S entities, etc. Now there are obvious reasons that whatever model you have, you wouldn't include it into your ASP.NET MVC application directly. You would probably reference it as an external assembly, and not directly place it in the Models folder.

So this begs the question. Do we just remove the Models folder? Well before I answer that, let me dig into something else.

Binding in ASP.NET MVC

We've seen many demos and tutorials where our model is directly passed in into our actions. We would have something along the lines of:

ASP.NET MVC's binding is pretty powerful. It can reflect on the properties of your class (even if they contain complex types) and match these up to the properties that come through over the wire, via the request POST. As long as you name the properties the same, it works like a charm. One issue that this introduces, as outlined by Justine in his post, as well as many others, is that the binding can come back to bite you. If you Customer entity has a field that you don't want the user to be able to update, you'll need to explicitly specify this by using attributes:

However, as simple as it might seem, it's error prone and violates DRY. Alternatives to this approach include creating custom model binders or using interfaces to specify the properties that you want to be databound. But let's hold that thought for a moment.

A typical update scenario for a typical entity

The following screen has a sample form to fill in the details for a customer

It's pretty standard. A bunch of fields and some dropdowns. But how is the dropdown values set? You could set them in the controller action just before displaying the view, using ViewData:

Now I don't know about you, but for me, using ViewData is a smell. If we don't use ViewData to pass information about our model, why should we be using it to pass information that our model indirectly consumes? And of course, being a dictionary that it is, it's prone to errors.

One plus one makes habitants for Models folder

We have two problems to solve:

Binding to only those properties that we need
Passing additional information to our views in a strongly-typed manner

Well this just cries out for a new class to encapsulate this information, i.e. a view model. Instead of binding directly to entities, you can bind to a new class that exposes only the information that is allowed to be updated. You can also use this class to provide other information required for a particular view. In the case of Customer, we could end up with something along the lines of:

In this case, we are using CustomerData as a DTO to hold the customer data (Name, Email, etc.) and the CustomerCreateViewModel as the View Model to hold other pertinent information for that particular view, for instance a list of countries. The action would now pass in this model as opposed to Customer:

We now have a strongly-typed model to represent all the information we need for a particular view, and since it pertains to the current MVC application and specific Views, what better place to hold this than the Models folder. Obviously based on your needs, you could provide a flattened version of this ViewModel but it does provide a cleaner approach to separate the actual DTO of your entity from the surrounding auxiliary requirements for a view.

Note: you need to make sure that you always provide a default parameter-less constructor for your view models since the framework requires this on binding.

Summary

By using strongly-typed views, you get the best of all worlds. You are able to make use of the binding provided by the MVC framework and it also provides a clean approach to providing specific data for views. And if that still doesn't cut it for you, think that you're making a home out of your Models folder!

Balsamiq. Just wow!

Hadi Hariri — Fri, 13 Mar 2009 16:21:52 GMT

Busy week for me this week. Between meetings, coding and real bad case of migraine, I've hardly had time to catch up with blogs or investigate new things. However, I did find a bit of time to look at two new tools, one of them being Balsamiq (the other tool, another blog post). I'd heard about Balsamiq some time ago but never really got round to playing with it until this week. And all I can see is that it's damn awesome.

What is it? It's a tool to do mock-ups of UI's. What makes it awesome (apart from the really low price tag), is that it's extremely easy to use and powerful at the same time. Take a look at some screen mock-ups

And here's the iPhone version of the "application"

So in 5 minutes (literally), I threw up a few mock-ups of some UI that I can then show the customer. The cool thing is that it's so easy to use, you can actually have meetings with the customer using Balsamiq and come up with a design together. Here's an image of the the surface design with some random controls:

I remember when I was doing mock-ups years ago using RAD tools like Delphi / Visual Studio. Man does this save time.

Love it! Definitely it's on my must-have-tools list. If you do any type of UI mock-ups, I highly recommend it.

Few days left for Early Bird for Architecture Days

Hadi Hariri — Wed, 11 Mar 2009 18:51:06 GMT

Just a few days left for the Early Bird fee for the iMeta Architecture Days. It's going to be a two day event in Madrid on Design Principles, Testing, and on the second day Domain Driven Design and SOA with Udi Dahan!

Since it's a training event, it's going to be a small group so there's more room for interaction. And all this is for just a mere 375 Euros. Price includes lunch and munchies on both days.

To sign up and more info, click here

Always room for improvement

Hadi Hariri — Sun, 08 Mar 2009 19:16:52 GMT

As if what Alt.NET is or isn't, whether it's mean or not, wasn't enough, now we have a new guy on the scene, and already the first reactions on the blogsphere (not to mention mailing lists and twitter world).

Well before I give you my opinion, let me ask a couple of questions:

Have you always written applications that have been bug free?

Have you always written applications that were a breeze to change and changes would not introduce new bugs?

Have you always written applications were the code was easy to understand after not looking at it for 6 months or for a newcomer to the team?

I haven't. I've worked on applications were I used to not sleep a day before a new deployment, not knowing whether those last minute changes broke something. I've picked up applications that took me weeks to figure out. I've been on projects of 7+ people were the bus number has been as low as 1, both as a developer and as a stake holder. I've learnt from my errors and I am continuously trying to improve the way I develop software to avoid making the same mistakes I've made in the past.

Unit testing, Test Driven Development, Dependency Inversion, Single Responsibility aren't required to make your software work. You don't need them to deliver applications. Your applications will still work without them. You can still link business logic to partial classes of datasets or hook them up directly to code-behind files in your ASPX pages. You can still use databinding with ObjectDataSources and your application will still work. You can still ship software that will work well for millions of hours with hundreds of thousands of users connected to it.

However, I'm quite certain that you'll suffer the consequences. I'm pretty sure, having been on both sides of the fence, that it will be easier to make a change to an application where you have a clear separation of concerns as opposed to the drag-and-drop version. It will be more re-assuring to make a change and have 90% of your unit tests pass, fix the remaining 10% and then deploy, as opposed to just ship and hope for the best.

That's why I write unit tests, to try and catch as many bugs that I introduce when making changes to existing software. That's why I apply principles such as SOLID, to make my code easier to change and more understandable

Alt.Net or the recent manifesto of Software Craftsmanship for me represent ways to improve my job and myself. Ways to develop software that will make it easier for me. At the end of the day, what I care about is what I'm responsible for, and that is myself, my team and the software I write. It's not about making a statement or trying to change the world. Another matter is if I choose to share my experiences with others, which I'm free to do. But it's not about forcing one way over the other.

Maybe the ways that I've learnt to improve up to now are not entirely correct. Maybe tomorrow we'll find better ways to write software, to make our life easier. However, I know that what I'm doing today is better than what I did yesterday. But that can only be accomplished if I'm willing to accept that I don't know it all and I'm open to improvement.

DDD Series

Hadi Hariri — Fri, 20 Feb 2009 20:16:24 GMT

If you're interested in Domain Driven Design, make sure you follow Casey's series on the subject. He does a very good job of explaining things clearly and answers many obvious questions that one initially asks when starting with DDD. Make sure you check out the comments also.

I'm not a Coding Horror, are you?

Hadi Hariri — Sat, 14 Feb 2009 15:37:09 GMT

According to you Jeff, 80% of developers are people that don't care much about improving the quality of their craft. In other words, it's mostly those who just care about the paycheck...programming is a job that pays the bills.

The remaining 20% fall in the category of those that read your blog (note the part in Italics):

But here's the paradox: the types of programmers who would most benefit from these guidelines, rules, principles, and checklists are the least likely to read and follow them. Throwing a book of rules at a terrible programmer just creates a terrible programmer with a bruise on their head where the book bounced off. This is something I discussed previously in Mort, Elvis, Einstein, and You:

Thus, if you read the article, you are most assuredly in the twenty percent category. The other eighty percent are not actively thinking about the craft of software development. They would never find that piece, much less read it. They simply don't read programming blogs-- other than as the result of web searches to find quick-fix answers to a specific problem they're having. Nor have they read any of the books in my recommended reading list. The defining characteristic of the vast majority of these so-called "vocational" programmers is that they are unreachable. It doesn't matter what you, I or anyone else writes here -- they'll never see it.

In the absence of mentoring and apprenticeship, the dissemination of better programming practices is often conveniently packaged into processes and methodologies. How many of these do you know? How many have you practiced?

Yet at the same time, as author of this blog and thus falling in the 20%, you state:

All those incredibly detailed rules, guidelines, methodologies, and principles? YAGNI. If it can't be explained on a single double-spaced sheet of paper, it's a waste of your time. Go read and write some code!

So which is it Jeff? Do we or don't we try and improve ourselves?

I don't fall into either of the groups, I'm not a Coding Horror. I'm one of those guys that tries to improve my knowledge, I try and learn continuously, either by myself or with the help of those that surround me. I don't just throw it all out of the window and claim that if there isn't a mentor around to help me, screw it. I don't give up if I can't understand it in a few hours. If others do differently, I try and understand why they do it differently.

To claim that I'm not going to need to, or not change my ways is very arrogant on my behalf. And the best thing is that I'm not alone. There are thousands of others like me.

So please Jeff, don't corrupt the profession just to justify your own ways.

[And to my reader (Hi Mom!), I will do my utmost best to refrain from writing any more posts about Coding Horror]

Demoware Cowboys

Hadi Hariri — Thu, 12 Feb 2009 08:12:34 GMT

My mother wants to become a computer programmer (not to be taken literally). And guess what, she can. With all the RAD environments nowadays you really don't need to know much about the basics of programming to make applications. You can use anything you want. First step, pick an environment. You have lots to choose from (Visual Studio, Delphi, Ruby on Rails). In under 1 hour you'll have your first application working. Next step, sell it.

Now do this for about 10 years, making a profit and you can claim that you're successful in software development. You can claim you've worked for 10 years and have never had to worry about things such as polymorphism, delegation, etc.

So when someone comes along with a post talking about weird things such as SOLID or how rules are meant to be broken, you reaffirm your position as a successful developer that has never needed or understood these concepts. And since the person writing this has 1.5M visitors a month and 125K subscribers, it's OK!

(You think I'm crazy. Read some of the comments on this post).

But It's NOT OK

I don't lose sleep over what I term demoware cowboys. Everyone has a right to make a living, however way they want. I'm the first person in the room that stands up to defend not needing to graduate in CS to have a successful career in software development. However, I also defend studying, understanding and practicing software engineering, and to continuously improve yourself. Just because you sell software and put food on the table doesn't mean you've accomplished all there is to in your field.

What does bother me however is people talking about things without truly understanding them. It's important to act with responsibility, specially when having so many followers.

Some of us write software for a living, as opposed to just writing about it, and it's not only about getting the job done.

Additional code just for testing

Hadi Hariri — Sun, 08 Feb 2009 12:06:36 GMT

Take a look at this code:

   1: public class ClassToTest {

2:

   3:     public void MethodToTest()

   4:     {

5:

   6:         IDAL dal = new DAL();

7:

   8:         int discount = dal.GetDiscount();

9:

  10:         if (discount > 10)

  11:         {

  12:             // Do something

  13:         }

14:

  15:     }

  16: }

The tight coupling to DAL just stands out like a sore thumb. One consequence of this tight coupling is that it's hard to test if we don't have an underlying database setup with correct values. Forget about testing this while taking a shower, unless you have a habit of taking your SQL Server box to the bath tub with you.

Take a look at the following approach to making this code testable without having a database:

   1: public class ClassToTest {

2:

   3:     public void MethodToTest()

   4:     {

5:

   6:         DAL dal = new DAL();

7:

   8:         #if testing_in_shower

   9:         int discount = 3;

  10:         #else

  11:         int discount = dal.GetDiscount();

  12:         #endif

  13:         if (discount > 10)

  14:         {

  15:             // Do something

  16:         }

17:

  18:     }

  19: }

Are you still here? Didn't you just fall off of your chair, not knowing whether to laugh or cry in anguish? It's just plain wrong isn't it? Code Smell just takes on a whole new dimension (and consistency?). Something like this shouldn't be done for many reasons. It makes our code testable but it's wrong.

Introducing code for testing purposes

The reason I bring this up now is because in the past 2 weeks I've seen a few references and examples of introducing code just for the sake of testability. Two weeks ago I was skimming over an article that was explaining unit tests. The class the author was trying to test had a dependency that was causing issues during his tests. The solution offered was to introduce a new constructor and inject the dependency in. In our case, the ClassToTest would like:

   1: public class ClassToTest {

2:

   3:     public ClassToTest()

   4:     {

5:

   6:         // Initialize some stuff

7:

   8:     }

9:

  10:     public ClassToTest(IDAL dal)

  11:     {

  12:         // Initialize some stuff

  13:         _dal = dal;

  14:     }

15:

  16: ....

Now that's great. The problem is that the author left both constructors in there, emphasizing that one is for testing purposes and the other for production code. Why that's wrong I'll get to in a moment.

The other day, Scott Hansleman made a blog post on testing some code that had a dependency on the current principal. His solution was to inject IPrincipal into various methods of the Controller, where Controller is in the context of an ASP.NET MVC Controller. Personally I don't agree with the solution but that's another subject (and another post on a different approach I have in the backlog for the same scenario). However, injecting the dependency seemed valid enough. Later on he updated the post with the following:

UPDATE: Phil had an interesting idea. He said, why not make method overloads, one for testing and one for without. I can see how this might be controversial, but it's very pragmatic.

[Authorize]

public ActionResult Edit(int id)

{

return Edit(id, User); //This one uses HttpContext

}
[Authorize]
public ActionResult Edit(int id)
{
    return Edit(id, User); //This one uses HttpContext
}
You'd use this one as before at runtime, and call the overload that takes the IPrincipal explicitly for testing.

The same thing has happened as in the case of an overloaded constructor. Code has been introduced into the base just for the sake of testability. In the previous case it was a new constructor, and in this case, a new method.

Why is this wrong?

Introducing code just so that you can test it is wrong for several reasons, including an increase in noise, decrease in readability and more importantly, permitting the possibility of production code that will not be tested. It might seem improbable at first, seeing that the overloaded versions always call the base ones, but as your code base grows, by allowing this habit, you can promote it to other structures such as conditionals, switch statements, etc, and not limit it only to methods or constructors. Then you'll start initializing values that only make sense in tests and gradually your code starts to smell more and more. To top it off, you can throw in some compiler conditional that rips those parts of the code out from the production version.

Code should also serve as documentation. The cleaner you make your code, the less noise and redundancy you add, the easier it is for others to understand and maintain.

Conclusion

Being pragmatic is good, but don't do it at any cost. Try and not introduce code into your code base that is there exclusively for the purpose of testability (and no, dependency injection is not only for testability). Anything that has to do with testing, keep it where it should be, in the test assemblies. Having overloaded methods or constructors, mocks or stubs in your code base is just as bad as having compiler conditionals in your code for testability. If you run into issue where your code is hard to test, step back and re-think your design. Maybe the problem you're facing now that's impeding your tests is actually a can of worms waiting to be opened. And the sooner you open it, the better. That's one of the great advantages of Test Driven Development.