MVC Survey related questions

.NET
1

This is just a feeler survey to see what people truly think about a few things. Answer as you wish, but try to include any reasoning behind your statements so others can ponder your points. If you don’t know the issues that each of the topics was created to solve, you may want to look into that before answering. I wlil assume all respondees are already aware of these issues. My own thoughts follow each question.

  1. Is dependancy injection / inversion of control really all that it is cracked up to be? Could you live without it if you’re employer announced that all future projects would use objects with multiple constructors instead?

When I began using mvc, I was not yet aware of DI / IoC, and so used the overloaded constructor method. Things worked as intended and so I never gave it a second thought. Later, when posting some of my code, somebody mentioned that it was poor man’s DI. I researched their alternatives and settled on using StructureMap for my DI needs. Over time (a very short time I might add), the library changed drastically, even between minor releases. This was just bad practice in my book, so I recently abandoned it, taking another look at Castle. While their code is more mature, I quickly became frustrated at some similar versioning errors, and the sheer number of dependant libraries. It seems to me that all that effort and headache could’ve been avoided by simply using overloaded constructors. This isn’t to say that you wouldn’t benefit from some custom factory / cache classes, but that maybe you should make these yourself and specific to your needs.

  1. How often do you find a project being significantly altered such that you actually see real benefit from using an orm abstraction layer such as nhibernate?

Personally, I’ve never seen such a thing happen in the nine years I spent in the field. Without exception, when the companies I worked for designed a product for a client, it typically went through a rigorous analysis period, sometimes over a year, just on paper. By the time we, the developers got our hands on things, it was simple a matter of bashing it out using pre-built interfaces. Once delivered that was it. Support was offered, but the product never changed on a fundamental basis. Never once did I hear of anybody coming back, wanting to switch from using MS SQL to Oracle, or MySQL. It just never happened. What is your experience with this?

  1. Is test driven design really worth the effort?

I am personally still not really clear on this one myself, but I’ll make a stab at it. While I can see certain benefits from it, usually in the testing of logic related objects, I see no real benefit of testing interfaces and simple dto classes. In one online example of TDD, part of the SharpArch docs, they demonstrate how to develop a business entity through testing. The impact of this fell on deaf ears with me. The things they tested for were just idiotic. The first test being: can we create an instance of the class? Well, using the test before code practice, or course not! The class hasn’t been written yet. This is just common sense. On the other hand, using an interface to create a mock concrete, and testing that for logical processing of data is a grand idea. Though again, this test would seem to be better done once the interface and classes are actually written. What are your thoughts on TDD and how has it impacted your efforts?

Again, this is a “what I have done and what I think” thread. Feel free to post opinions, just back them up.

2

HAAA! had a big text typed and browsed to another page to look the link for this

DI -> http://oredev.org/videos/breaking-out-of-dependency-hell

I only play with this stuff in my home/pet projects, a way to keep studing and learning. My day jobs is pile of … a mess.

  1. Have you realised the amount of work a orm saves you… If you only have 3 or five sprocs/sql-statements you will not notice it much. In the last project I worked that we used sprocs in a team of 7 devs, 3 were only writing pl-sql and half of my time was writting plain ado.net data-access code.

  2. I try to write test for the stuff I do at home. I think the key with TDD is to “design” in your tests, and take a wishful thinking aproach. And I don’t think the goal is to have a test/assertion for every line of code. You should test a class from the outside, its interface, not its internals.

http://www.dimecasts.net/Casts/CastDetails/70

The last tech book I’ve read - Growing Object-Oriented Software, Guided by Tests , was realy an eye opener on what is the goal and what is the aproach you should take with tdd.

cheers,
rui

3

lol @ pufa. I’ve lost many posts by alt-tabbing and other things! It’s infuriating. Anyway, regarding point two: yes, I realise they can, and do save a lot of time. But in my observations, that is highly dependant on how much, or little, time you’ve put into stockpiling generic classes from the past. For instance, I have numerous interfaces and abstracts that I’ve saved from one thing to another that make a new project a lot easier, like my Linq library. So yes, it’s still an orm at heart, but it just doesn’t appear that way from the new project point of view. Just reference the library and you’re off. In essence, this is exactly what NHibernate does. The difference though is that mine is custom written to handle Linq abstraction only. Maybe I should refine the question to: is it more worthwhile to unquestioningly use a thrid party app, abstracted for ALL possibly scenarios, and invite possible bugs that you cannot fix yourself, or spend a little time up front writing your own libary?

4

I was in the middle of writing a long reply too, but my girlfriend distracted me, and before I had a chance to finish she had stolen the PC and was playing the Sims 3!

  1. Yes it’s worth it. We use iteration based development, with iterations of 2 weeks and need the ability to easily modify code. A DI and IoC container allows for this, and Castle comes with a range of other components we take advantage of (NHibernate integration, Transactions managements, etc.) to further reduce the complexity and the amount of code we have to write. The dependency hell is something to be aware of as it can quickly get out of hand. Properly managed, this risk can be reduced. We have centralised the distribution of our OSS references, and one person is responsible for keeping these up to date, unfortunately that person is me! I would strongly resist my employer trying to dictate how an application should be designed and developed if I felt strongly that it would have a negative impact. I would insist of a proper discussion involving everyone a decision like that would impact and review the cons and pros. Fortunately, I’m in the position where I have a lot of say in how we design applications, and employer and boss hired me because of my experience. If I felt that I was forced to compromise on quality, and development decisions where forced upon me, I would move on to another position.

  2. We need tools that are going to support being able to change easily in as little friction as possible. Using a good ORM is a must, and the best ORM on the .Net platform is NHibernate with FluentNHibernate. POCO is extremely important in an iteration based, TDD designed application, and an ORM that allows for this without imposing too much on your design is a must. While we use two RDBMS’, Sqlite for testing and Sql Server for production, this isn’t the primary reason. Using an ORM reduces development time and the impact of change. Our domain drives our application and data structure. Removing the database from a core component of the application really helps increase the flexibility of an application. It also greatly enhances the ability to test things in isolation easily. We do very little up front design, I personally feel its a waste of time and resources. We prefer to get something in front of the client in a few weeks instead of a years worth of analysis. I’ve worked in places that did the BDUF, it and always caused pain. An iteration based development process is far more flexible, and I’ve had far more success with it. Being able to hand the client working code for the requirements they defined 2 weeks ago is far valuable than a collection of documentation and UML diagrams produced over a year!

  3. Absolutely, if your project is big enough. For small projects, I might forgo TDD, but I will still develop code using SOLID. The problem with TDD examples is trying to keep them simply enough to understand, but this can make the process look redundant. Because we are constantly changing the application as the requirements are refined, we use TDD to ensure things don’t break and works as documentation for yourself and others. TDD is an investment and will add time in the short term. In the long term, for any projects that will be around for awhile or developed iteratively, TDD is a core component of reducing risk and enabling project wide awareness of any unforeseen impacts of new or modified code.

  4. (Question above) I’m a massive fan of writing as little code as possible, and when I do, its not boilerplate code, ceremony code for configuration, etc. I want it to the the fun, interesting business problem solving code that I’m actually getting paid to write. We use OSS projects for as much as we can, and use projects that are recommended or popular. However, it’s important to minimise the surface area between your code and the OSS code, a small abstraction can really enhance productivity and minimise the impact of when the OSS code changes. I prefer to use OSS code that is being used by a others too and not something I have to maintain.

Disclaimer: I work large, long lived applications for large companies with complex domains in my current position. I have worked in places where the investment in some of the above would not be worth it (small, simple sites, for small businesses, hotels, etc.). It’s all about value and managing the impact and risk of change and is completely subjective in most cases.

5

Here is an interesting blog post of the 8 stages of TDD: http://codebetter.com/blogs/karlseguin/archive/2010/03/09/the-8th-phase.aspx