It’s official, fix the date: 14-06-2008, fix the location: Milan.

That’s the day of the second ALT.NET Conference, if you want to join us you can take a look here (sorry the page is in Italian :-|).

The day is focused on developing a blog engine using the agile methodologies, the ASP.NET MVC, IoC and all the others things that we like.

During this days, we are planning to write some stories that we will implement at the conf, so you can help us if you want on the mailing list of italian ALT.NET movement (here).

Claudio has joined the blogosphere opening a new blog here:

http://testdrivendevelopment.wordpress.com/

The name speak for himself.

You know that you are addicted to Resharper when while writing a document with MS Word you press ALT-Enter to correct a grammar error!

In these days I’m having a discussion with some DBAs about the pros&cons on using stored procedure to access the database.

I don’t like stored procedure for various reasons. The main one it tight to code maintainability. If you begin with one SP you end up you application with thousand of SPs that extract data from database in multiple forms (the customers ordered by name, the customers filtered by country, filtered by company, filtered by whatever).

What happen when I need to add a new field to the customer table? A mess!

Another reason is about business logic location. In my opinion the user request "I want to view all the customers filtered by Country" is a business rule, and as a business rule I want to code that in the business layer of my application. So I don’t want to code that in T-SQL but I want to code that in a high level, object oriented, strongly typed, debuggable, testable, manageable, readable language: C#, Java,…

One of the arguments that DBA take in favor of SP is performance. Apart that I’m not so sure that the SP give more performance (read here), are performance always the most important thing?

I agree if we talk of reporting applications, or application that have a HUGE database that has to be responsive in milliseconds (automation industry for example), but most of the application are used by humans that count in seconds, not milliseconds. So performance in not a real issue, you can get the same with ORM (if it’s rightly tuned).

Maybe the solution will came when the database vendors fill the gap between application world and database world making database more abstract from the physical representation of data.

I want to think in objects not in bytes. Instead the DBA still today has to think in bytes!

I talk some months ago about T-SQL like an assembly language for database, you can read it here.

The famous three R of the Reduce Reuse Recycle motto are very much used in the enviroment field, but they can also be applied to the programming world.
A good programmer takes care of the ecology of his own application, since the code of the application is the enviroment where he spends a lot of his working time. If the application is developed respecting the enviroment where it runs, it is surely an advantage for the whole virtual ecosystem.

Reduce: reducing the code. It seems strange, but it is often more difficult cancelling some code than adding some new one. Adding too much code is often due to overengineering, by implementing functions that are not stricly necessay, and that do not give an additional value to the final customer. It just contribute to pollute the application, making it difficult to maintain. Therefore reduce the code dimension brings to remarkable results: simplification of codebase, ease of maintainance, and in general an improvement of performance.

Reuse: do not invent the WHEEL every time. Writing classes that can be used again or using library of third parts that already do the requested task, is a good habit. Using a class, that was already writtne, brings advantages boths in terms of realization time than in terms of debugging time (hoping that the class you are reusing is bug free…)

Recycle: it may sometime happen that a class could be reused, but it is not exactly as we need. So, sometimes by using CTRL-C, CTRL-V you just introduce duplications and polluted code. If you do some refactoring you could reuse a part of the code already written adapting it to the new application. Also in this case the advantages are a lot: the quantity of the code we are adding is lower, we avoid to create classes that are too alike (or even identical) and of course we spare time and we do not pollute.

I like this idea of the enviromentalist code, as in general all the enviromentalist attitude.

What do you think about it? Do you feel code enviromentalist?

Last week, during the launch of the Visual Studio 2008 and all the 2008 wave, me and Andrea received the heroes book, where on page 40 you can find our photo.

It is a big joy to be on that book with others 80 teams of all over the world.

Thanks to Microsoft, Carolyne and Selcon.

Anyone who has tried to write a test had to solve the problem to write a test that hit the database to write a record in a table with a high number of foreign key. Writing these tests result in a big overhead to put the database in a consistent state before write the real test.

Which approach can we use?

I found two approaches that I like.

The first one is to have a test only known database. If you know the database you know that a particular table have the particular value with that particular ID and you can use this ID to build your record to insert. For example if you need to test the insert an Address you can use a known city to manage the foreign key:

[Test]
public void SaveAddress_CreateANewValidAddressAndSaveItOnDatabase_ShouldSucced()
{
  AddressService as = IoC.Resolve<AddressService>();
  Address a  = new Address();
  a.Street = “via Mantova 6“;
  a.City = GetBrescia();

  as.Save(a);
  // …Asserts…
}
private City GetBrescia()
{
  return new City(Id=5, Name=“Brescia“);
}

The hypothesis is very strong and maybe too restrictive and difficult to respect when the database is quite big and change a lot during the development. For these reasons sometimes is better to rebuild the entire database on every test session using a TSQL Script (a script that build the tables and insert the data).

A second approach is to let that every tests is responsible to prepare the database tables that need to use. In the previous example the Test should insert the city of Brescia in the Cities table getting the ID (from database) and use this ID to build the city object.

The differences with previous method is that in this one the tests are more independent from the database and every test is responsible for his own data, on the other side the second approach is more verbose because you need to write a lot of code to insert the data in the database (and remove it too!).

I usually prefer the second approach, is more maintainable and clear in big application, even if the first is better for small applications.

F2: rename the selected symbol (field, variable, method, etc…)