Unit Testing in VS

Can't believe it, every time I look at it, how comical it is - generate unit tests from code.

Yeah, it allows you to get tests up and running quickly, but makes one big supposition - that the code that you're generating a test for actually works.

Make TDD easier, and remove the feature, it's silly.

Martin.

LINQ

Hey guys!

I have to say, I'm a little disappointed.

Having played about with LINQ briefly I thought it was a really good idea, especially having to not need to work out complex joins and the like. I thought that is was a really good idea.

If you push the technology to the point where you threaten to use it in an enterprise solution, I found that whilst you don't have to work out the SQL side of things, or the joins, really you do. Some unexpected side effects within LINQ, such as not being able to mix and match LINQ to SQL and LINQ to Objects, so running in to problms with code re-use means that the technology requires a much more in depth knowledge than one might be required to learn to use stored procedures.

I also found that performance in the simple scenario was great, but again, if pushed hard the technology was not great performance wise. That meant that using LINQ meant mixing and matching the LINQ language with stored procedures, which in my mind at least undoes it's purpose - language independence.

One other thing - if you want to keep a traditional data layer, without any technology bleed, and make LINQ work properly, well basically, you can't. It seems that each layer having its own model, whilst a good idea in theory isn't something that you'd really want to do with LINQ. I might be being unfair to technology, but from what I could see, the LINQ objects needed to be used to keep state information, which makes the technology basically a desktop technology, much like the dataset in a lot of ways, but with a fancy language to sit in front of it.

I'm going to keep going with the technology, as I like the concept, to see if I can find a way around it, to make use of it in such a way that it is actually useful, but at this point, it simply seems like a fancy language, with some very cool technology, but no real follow through. Really, that's a shame.

Static classes and methods?

Hi,

Here's something that I really feel most people miss - questioning why they do something design wise.
A lot of people use static classes for reasons of laziness, it's easier to declare something as static than to create an instance and call methods on that.

Here's the thing, static classes generally go against OO design, you can't put an interface to a static class. That means that the code is going to be coupled to implementation, and so is not as easily maintainable.

I love unit testing, ideally with mocking, so my natural inclination is toward dependency injection. The resulting code due to following this approach with TDD is naturally a lot cleaner.

All static classes should be a thin veneer on an instance class, and so are then implementing a singleton pattern. I can see no other need for a static class - there's always an easy way around any other argument I have come across.

Take for example that it's nice to have access to a static class such as, MyDataLayer.Save(data). Instead how about defining a private property within the class, and lazy instantiating the reference within the property get? So for example:

private IDataLayer DataLayer
{
get
{
if (_dataLayer == null)
{
_dataLayer = new MyDataLayer();
}
return _dataLayer;
}
}

The only excuse you could have here for not using this approach is being lazy. This also allows you to inject dependencies through a special constructor, and the code will still work, so you can still unit test, and still get the easiness of static classes without all the drawbacks!

Happy Coding!

Martin.