I see your points though and agree the additional casting back to a List to use the operations needed and checking whether the cast was successful can be tedious. I wouldn’t label the ‘size’ of the project as the hard line in the sand factor on using Interfaces; we all know the ‘small’ projects that balloon into the enterprise projects and those are the ones built with the worst foundation because it was originally thought of to be a ‘small’ project. Rather, look at potential scaling of the application, and it ‘could’ blossom into something larger, and then heavily consider a more OO design using Interfaces like IList.

I find the new Generic list built in methods real helpful, and it means you don’t need to write your own versions of it to extend the IList, IEnumerable etc etc, which when you think on it, would mean everyone would need to have access to the DLL with the extension method, or they could just use the List object

I do get all the idea of good use of iterfaces, and especially when it comes to DI – the idea of being able to change the logging mechanism of an error handler or a shopping cart is quite nice and lends itself easily to the loosely coupled code. But I cannot foresee myself changing the database from SQL Server to MySQL without needing to change to PHP

I did a test tonight. I have a database table with 7840 towns and villages from different countries around the world. My code I have set up so that I can save into cache quite easily.

My first test was to iterated around a list in cache 10,000 times to find a random selection with 2 characters in it’s town name:

for (int ii = 0; ii < 10000; ii++)
{
searches = new RM_TeacherService().FetchAllSearches();
contains = alpha[rnd.Next(0, 25)] + alpha[rnd.Next(0, 25)];
output = searches.FindAll(search => search.Town.Contains(contains));
}

This use the .NET built in FindAll on the objects I retrieved from the database, and then after the first call, the .NET cache object. It takes on average 123 seconds to run. I thought that was a bit piss poor really. I got upset thinking Dave was right again… So I did this to for his side of the argument:

for (int ii = 0; ii < 10000; ii++)
{
contains = alpha[rnd.Next(0, 25)] + alpha[rnd.Next(0, 25)];
searches = new RM_TeacherService().FetchAllSearches(contains);
}

Where FetchAllSearches this time takes the 2 character and goes the SQL Database each time, only returning what it gives me. What made me laugh was on average it was 140 secs to repeate 10,000 times. So the in memory List was 17 seconds faster (divide that down by the 10,000, each iteration is 0.0017seconds faster. So really it’s not a performance issue, unless you are doing massive amounts of searches and stuff and for some reason need to hit your database 10,000 real quick.

However this was an extreme case, with 7840 items. That would be a very unrealistic thing to do, and it is better with data sets that never change, and are real small e.g. lists of Areas in Scotland. But the difference as seen can be negligable, it’s just a matter of choice if your database server is already getting massively hit.

Your find method would look something like above. However ipnonr ain’t too good for writing code lol. I’ll send u better one tomorrow
}

Massive performance loss. Find the boundaries and stick with them.

MS provide some helpers for you, but 99% of the time they miss the point.

Here we have an example of what I said on the other comment.

using System;
using System.Collections.Generic;

namespace NinjaTools.Helpers
{
public static class EnumerableExtensions
{
public static IEnumerable Each(this IEnumerable collection, Action action)
{
foreach (var item in collection) action(item);
return collection;
}
}
}

// find all pages with the title is like “Colin”
IEnumerable iPages = new CMS_PageService().FetchAll();
List found = new List();
foreach (CMS_Page page in pages)
{
// blah this is baws!!
if(page.Title.Contains(“Colin”))
found.Add(page);
}

but with .NET’s generic List object you can do this:

// find all pages with the title is like “Colin”
List pages = new CMS_PageService().FetchAll();
var tmp = pages.Find(page => page.Title.Contains(“Colin”));

and that is much much nicer! No? So why do I want IList and IEnumberable for all my service classes, when I don’t expose them further than my own websites?

I’ll go over that in the pub in Kowloon too

Anything like array list etc all implement ienumerable at their core

Following me?