C# OO Design Question

Question

I have a windows form app written in C#. the main_form class instantiates an AccessProcess named AccessProcessWorker which is a class that inherits from BackgroundWorker, then main_form then initializes Process with the following code

        AccessProcessWorker.DoWork += new DoWorkEventHandler(processWorker.worker_DoWork);
        AccessProcessWorker.RunWorkerCompleted += new RunWorkerCompletedEventHandler(processWorkerCompleted);
        AccessProcessWorker.ProgressChanged += new ProgressChangedEventHandler(processProgressChanged);

this application has just gone from POC to "make it work fast".

I wrote this app to work against an Access database but now want to make it go against MS Sql, but leave the option to work against access also. So, I could do something ugly like instantiate and initialize a SqlProcessWorker or AccessProcessWorker based on some UI selection made by the user. But what I'd like to do is make it so main_form always creates something like an IProcess so I didn't have to add logic to main_form every time there is a new ProcessWorker. The problem in my design is that the initializing breaks when I do it the way I described.

If anyone has any ideas, or need further clairification please let me know.

Answer 1

At some point you will need to instantiate the correct type, but The Factory Pattern is usually to the goto here. Now, that may be a bit much if you will only ever have one of two types to 'new' in order to get your IProcess object.

Answer 2

What you look for is called "dependency injection".

Answer 3

In the interests of keeping it simple, I would actually just go with the "ugly" approach.

You've mentioned Access and SQL Server as the two current databases, but how many do you realistically believe your app is needing to support? In my experience an application's database platform is very rarely changed and not without serious thought.

If there were a large set of database platforms to support and you can't predict which in advance, then maybe a decoupled design would be useful. Otherwise KISS.

Answer 4

If both of the database are the same layout and structure, you can just use EntitySpaces and change the default connection of the application. I.e. you have one code base when it comes to data access and then you just set the current connection based on whether you want the Access or SQL Database.

Answer 5

I would wrap the "ugly" bits of code in a separate method, or preferably a class which takes care of choosing which DB to talk to and the synchronization with the actual BackgroundWorker instances. The important point here is to adhere to the DRY principle: Don't Repeat Yourself.

Answer 6

I think that for a work project, you should do it as fast as possible, without thinking of future databases, because it's probably not gonna happen.

Are you sure there's not, somewhere, a class which already works with both Sql Server and MS Access? For example, OleDbConnection, OleDbCommand? For simple SQL, all you need is to change the connection string and you can work with both databases.

If you haven't coded the rest of the application yet, you should take a day or two to look for some frameworks, compare and choose one of your liking. It'll make you write less code, and in future apps you'll be spared most of the database plumbery code. I guarantee that the time invested will be returned to you manyfold (if you work with databases once in a while, that is).