Posts in category .net - page 20
I first encountered the Gang of Four Design Patterns book back in 2001 when a friend lent me a copy. I didn’t immediately get it, most likely because my object oriented experience up to that point consisted primarily of small Delphi applications.
In the last few years I’ve been working on much larger systems and have come to appreciate design patterns enough to get my own copy and also to invest in Martin Fowler’s excellent Patterns of Enterprise Architecture which provides higher-level patterns aimed at large data-driven applications.
One of the design patterns presented, and indeed a core component of the Ruby on Rails framework, is that of the ActiveRecord which attempts to provide object-relational mapping.
It achieves this by specifying a single class per database table where instances of that class represent a row in the table – exposing a property for each field the row has in the database. Each ActiveRecord instance is therefore effectively a domain/business object.
So far so good but then the ActiveRecord pattern ignores the single responsibility principle by specifying that the object should also include a bunch of static methods for managing the table’s contents and retrieving instances.
What you end up with is one object with two distinct responsibilities separated by nothing but the static keyword. Static methods and fields can serve a useful purpose but dividing up responsibilities isn’t one of them and neither is to provide global-like access across your application (Singleton abusers take note).
I can think of at least two reasons why gluing two candidate objects into one physical one using the ‘static’ split causes ActiveRecord to suffer with problems:
Sometimes an application requires connections to more than one database (e.g. reporting, aggregation, upgrading tools, per-user switching of database in a web application).
Static methods often rely on static fields which means you’re going to have trouble making the
data you’re going to have trouble making them behave like objects.
There are three types of inheritance mapping techniques available.
- Concrete Table Inheritance – one table per concrete class containing columns for all fields of the class regardless of where they are declared
- Class Table Inheritance – one table per class in the hierarchy containing columns for fields of the class they are declared in only
- Single Table Inheritance – a single table for all classes in the hierarchy containing all columns for all possible sub-classes many of which will be null
Concrete Table is most likely where the tables created by the parent classes would have little or no value and Class Table where they do.
Single Table is what ActiveRecord implementations such as Ruby on Rails tend to use although quite how it works I’ve yet to discover… Does the parent class magically know enough about it’s child classes that it’s static methods can handle the update/select/delete? Can I ask the parent class for all objects and get a mixed collection back?
Fowler presents a number patterns as alternatives and many object-relational mapping (ORM) solutions including LINQ for SQL utilize them.
AnkhSVN 1.0 has been released!
If you use Visual Studio 2003 or 2005 and are currently either using the TortoiseSVN shell extension (or Subversion command line) then you would do well to see just how much more productive having source-control available from within the IDE can be.
|Thanks go to Arild and mac||gyver for all their hard work on this great open source project.|
Hope you enjoy my icons too!
If like me you have a couple of machines, a few virtual machines and secondary installations such as Express editions (for XNA of course) you can easily loose track of which have been patched with service pack 1. Especially if you also messed around with the SP1 beta.
Help > About from Visual Studio 2005 can tell us – cryptically…
No service pack – Version 8.0.50727.42 (RTM.050727-4200)
Service pack 1 beta – Version 8.0.50727.363 (SP.050727-3600)
Service pack 1 – Version 8.0.5727.762 (SP.050727-7600)
Burge points out that clicking Show updates inside Add/Remove Programs reveals the SP1 update nested beneath Microsoft Visual Studio 2005 xxx Edition – although it doesn’t tell you if you still have the beta installed.
While Visual Studio is quite a capable IDE it isn’t perfect – here is my personal top 10 list of things I hate about it. I’ve kept the gripes to the IDE itself – the issues I have with .NET Framework deserve a post of their own some time.
1. Go To Definition does not work between languages
Sometimes your solution has to be a mixed language one – you know the odd VB.NET class library that nobody wants to rewrite in C#.
Hit Go To Definition on a call to this library however and you won’t find yourself there in the VB.NET code – oh no it’s straight to the Object Browser for you.
2. IntelliSense ignores aliased name spaces
Name spaces were introduced to help reduce name collisions but occasionally you need to use both classes with the same name. You get two choices in .NET – you can either fully-qualify them making your code incredibly verbose and difficult to scan through or you can use an aliased name space – e.g.
using SNM = System.Net.Mime;
Annoyingly IntelliSense will always use the fully qualified name even if you start with the alias. Typing
SNM.ContentType content = new will trigger off IntelliSense to unhelpfully suggest
3. Dependent-upon project items aren’t usefully exposed
.NET 2 brought partial classes to the table and Visual Studio made a stab at using them for the Form designers by sticking the generated code in a .Designer file that nests below the file in the Solution Explorer.
This is achieved by the .Designer file gaining a
<DependentUpon> tag to link it to its owner. If you want to use this for your own generated files you’d better get used to editing project files in Notepad because the IDE won’t help.
4. The SDK/AddIn API is awful
If you feel like addressing any of the shortcomings in Visual Studio you can extend it using their SDK which allows you to write your own AddIn – providing you can get your head around the most obscure and awful API ever.
5. Not all project types support automation
Some of the less popular project types (e.g. Database) don’t support the parts of the automation API they are supposed to.
This means if you’ve managed to get your head around the SDK you now find all your hard efforts don’t always work.
6. The syntax editor does not support italics
Why oh why doesn’t the syntax editor support being able to italicize a font? I’d much prefer my comments displayed in italics. If Borland’s Delphi supported it in the 90’s why can’t Visual Studio 10 years later?
My Envy Code R programming font fakes italics for use within Visual Studio!
7. Document tab area doesn’t like staying still
The document tab at the top of the screen is where you switch between the various documents. The only problem is it jumps up and down depending on how many tool bars as standard the designer/editor for that file type has so you switch once and then end up hitting a random tool bar button if you quickly decide to move on to another file.
8. No re-distributable elements
Want to put syntax highlighting in your product? Better go buy some third-party components.
Visual Studio style docking? Third party-component.
Sure you can license the basic Visual Studio IDE for your own languages and code – providing you have very deep pockets.
Wrapping it up
I’ve downloaded the January CTP of Orcas but I doubt it will address any of my bug-bears.
What would be cool is an open-source IDE for .NET development written in .NET that exposes the syntax highlighter and parser trees with a much better plug-in system and the Office 2007 style ribbon.
I wonder how the SharpDevelop guys are getting on…