Thursday, October 2, 2008

Does C# need the Template pattern?

My understanding of the Template pattern is that it allows a programmer to provide a hook for outside use into a classes methods. With the advent of C# a new type has come into use, the Delegate. From the MSDN site
A delegate is a new type that references a method. Once a delegate is assigned a method, it behaves exactly like that method. The delegate method can be used like any other method, with parameters and a return value...


This sounds to me like a perfect candidate to hook into a method. Now maybe the Template pattern is still useful in other ways, although I haven't come up with one, but maybe Delegates can make it largely obsolete.

Some quick sample code I did to just test it out.

namespace DelegateTest
{
public delegate int Test(int MyInt);
class Program
{
public static Test MyTest;
static void Main(string[] args)
{
int SomeNumber = 5;
MyTest += new Test(MyInt);

if (MyTest != null)
{
SomeNumber = MyTest(SomeNumber);
}
Console.WriteLine(SomeNumber);
Console.Read();
}

public static int MyInt(int TestInt)
{
return 6;
}
}
}

Friday, September 19, 2008

Strategy Pattern

I found a very useful purpose for the strategy pattern. I am writing an application that will move all or part of a database depending on the users selection. Since 90% of the code was the same I decided to use an abstract class with concrete methods for the business logic that was the same and abstract classes for where it differed. The strategies I have to choose from are:

1. Move entire DB
2. Move all rows from X number of tables.
3. Move X number of rows from X tables.

Doing a quick mock I came up with

public abstract class DBMoveStrategy
{
//properties...

//events...

//concrete methods

public abstract void GetSource();
public abstract void AddConstraints(DataSetFacade Data);

}

Then I sub-class for the different branches of logic.

public class DBMoveAll : DBMoveStrategy
{
public override void GetSource()
{
//some code
}

public override void AddConstraints(DataSetFacade Data)
{
//some code
}
}

public class DBTables : DBMoveStrategy
{
public override void GetSource()
{
//some code
}

public override void AddConstraints(DataSetFacade Data)
{
//some code
}
}

public class DBMoveRows : DBMoveStrategy
{
public override void GetSource()
{
//some code
}

public override void AddConstraints(DataSetFacade Data)
{
//some code
}
}

To use this inside another class I just do the following:

public class MyControllerClass
{
private DBMoveStrategy movedb;

public MyControllerClass()
{
if (IsMoveAll)
movedb = new DBMoveAll();
}

public void Connect(string Server, string Database, string UserName, string Password)
{
movedb.connect(string Server, string Database, string UserName, string Password)
}

public void GetData()
{
movedb.GetSource();
movedb.AddConstraints();
}
}


There is more logic involved but this will give a flavor for how I am using the pattern. There are probably some better ways I could use it or other patterns that might be better but I am still learning the language and better ways to write code.

Friday, September 5, 2008

Event Driven Error Handling

I have been reading a new titled "Design Patterns in C#". It is a great book, tons of information and it is quite understandable. While reading through the observer pattern it struck me. Why do we need to use so may try/catch statements in our code when we could fire off the exceptions from an event handler.

So I wrote up some quick code to test it out.

public delegate void TestErrorHandler(string message);

public class TestClass
{
public event TestErrorHandler test;

public void TriggerHandler(object blah)
{
if (blah == null)
{
test("Null argument in TriggerHandler");
}
}
}

static void Main(string[] args)
{
TestClass MyTest = new TestClass();
MyTest.test += new TestErrorHandler(OhCrap);
MyTest.TriggerHandler(null);
}

public static void OhCrap(string e)
{
Console.WriteLine(String.Format("Oh CRAP! {0}", e));
Console.Read();
}

I can see some pitfalls to this solution like:
1. You fire off the same Exception Event from multiple methods, i.e. ArgumentNullException.
2. How do you tell what observing method called the method that threw the Exception Event? For instance what if you had a private property that had the same methods being called multiple times?
3. What about if I call the same method multiple times from the same piece of code. a for loop for instance?

These are definitely challenging issues to solve but I feel it may be possible. I already have some ideas but right now don't have the time to fully test these out. If it is possible then it could take decoupling code to a whole new level.

Monday, August 11, 2008

Updating identity columns in a Dataset

One of the things I have noticed about working with DataSets is that there is not a lot of information out there on how to work with Foreign Key constraints and merging 2 databases together. Let me rephrase that, there is a but it feels scattered about and I felt it didn't teach me what I needed to know. After spending some time researching the subject here is the best way I have found to deal with the issue.

First you need to setup your connection.

string ConnectionString = "server=" + _DatabaseServer + ";user id=" + UserName + ";password=" + Password + ";Trusted_Connection=no;connection timeout=30";

Establish your connection

Connection = new SqlConnection(ConnectionString);
Connection.Open();

Now we setup our adapter
string ParentQuery = "SELECT * FROM ParentTable";
string ChildQuery = "SELECT * FROM ChildTable";
SqlDataAdapter ParentAdapter = new SqlDataAdapter(ParentQuery, Connection);
SqlDataAdapter ChildAdapter = new SqlDataAdapter(ChildQuery, Connection);

At this point we can fill our DataSet. Before we do we need to setup an event handler for updating the Identity column in each row when it gets written back to the database. The reason for this is depending on how you you merge DataSets or add rows to a DataSet the Identity column will have a place holder. This place holder will not necessarily be the same value as what the database will contain. This wouldn't be a problem if you were only updating 1 table but when you have child tables that need the same value you will run into issues.

Here is where you add the event handler

ParentAdapter.RowUpdated += new SqlRowUpdatedEventHandler(AdapterRowUpdated);

And here is the event handler

private void AdapterRowUpdated(object sender, SqlRowUpdatedEventArgs e)
{
SqlCommand IdentityCommand = new SqlCommand("SELECT @@IDENTITY", e.Command.Connection);

e.Row["ID"] = IdentityCommand.ExecuteScalar();
e.Row.AcceptChanges();
}

Now when you Update the database all your rows will have the same IDs.

Go ahead and fill our DataSet.

ParentAdapter.FillSchema(MyDataSet, SchemaType.Source, "ParentTable");
ProfileAdapter.Fill(MyDataSet, "ParentTable");
ChildAdapter.FillSchema(MyDataSet, SchemaType.Source, "ChildTable");
ChildAdapter.Fill(MyDataSet, "ChildTable");

We have 1 DataSet with 2 DataTables in it, ParentTable and ChildTable. The database has an Identity field and a Foregn Key constraint. Those are not replicated down to the DataSets so we have to do this manually.

The Unique constraint
UniqueConstraint ParentConstraints = new UniqueConstraint(new DataColumn[] { MyDataSet.Tables["ParentTable"].Columns["ID"] });
MyDataSet.Tables["ID"].Constraints.Add(ParentConstraints);

Pay attention to the UpdateRule setting for the Foreign Key constraint. We set it as Rule.Cascade. This is done so that when we update the ID column for a row that ID gets propagated to any row within the child tables that contain the same Identity.

ForeignKeyConstraint ParentFK = new ForeignKeyConstraint("IDFK",
MyDataSet.Tables["ParentTable"].Columns["ID"],
MyDataSet.Tables["ChildTable"].Columns["ID"]);
ProfileFK.UpdateRule = Rule.Cascade;
MyDataSet.Tables["ChildTable"].Constraints.Add(ParentFK);

If you are merging 2 databases together I would recommend following the same steps above for the second database. That way you have 2 identical DataSets when you go to merge them together and you can reuse all the same code again. You don't have to do this if you don't want to as there are ways around it by using MissingSchemaAction but I prefer to have identical DataSets to work from.

We have 2 DataSets and we need to merge them together. The problem is that when you Fill your DataSet by default it sets all Rows to a RowState of NoChange. This means when you merge your 2 DataSets nothing will get written to your database because nothing has changed. Any new data should be marked as Added so the Adapter will Insert it into the database when you perform the Update. This is not very efficient if you have multiple tables that need to be updated. In that case wrap the below foreach loop in another foreach loop to iterate through each table.

foreach (DataRow row in NewData.Tables["ParentTable"].Rows)
{
row.BeginEdit();
row.SetAdded();
row.EndEdit();
}


Merge the 2 DataSets. This is very easy using the Merge method in your Destination DataSet, NewData being the DataSet I want to merge into my existing data. You have to set preserveChanges to true or the Merge will throw out all your changes and nothing will make it into the new database.

MyDataSet.Merge(NewData, true, MissingSchemaAction.Add);

Our DataSets are now merged and ready to be Updated in the new location. This is pretty trivial. The only thing to remember is that the Identity column is marked as ReadOnly, therefore you can't update it without first changing it.

SqlCommandBuilder ParentCommandBuilder = new SqlCommandBuilder(ParentAdapter);
SqlCommandBuilder ChildCommandBuilder = new SqlCommandBuilder(ChildAdapter);
MyDataSet.Tables["ParentTable"].Columns["ID"].ReadOnly = false;
ParentAdapter.Update(MyDataSet.Tables["ParentTable"]);
MyDataSet.Tables["ParentTable"].Columns["ID"].ReadOnly = true;
ChildAdapter.Update(MyDataSet.Tables["ChildTable"]);

Now just check the destination database and everything should be there. Just repeat the steps above for multiple tables and multiple databases and you can merge as many databases and tables as you need to.

Friday, August 1, 2008

Mocks and stubs

I am getting to a point where I am designing more and more complex applications. Since I am doing this alone I sometimes find it over whelming when I realize everything I am going to need to do as I progress though an application. Combine this with performing TDD at the same time and you begin to realize just how much work you have ahead of yourself.

Some of the things that I have begun to use in order to make things easier are mocks and stubs. I first heard about mocks and stubs while researching TDD and am beginning to use them for more than just testing. There are some subtle differences between mocks and stubs but they are similar.

Stubs are methods or functions that are only meant as place holders. I have yet to see a stub actually do anything. An example of a stub would be:

public static void SomeMethod(string MyString)
{

}

It doesn't do anything but it will allow code to compile that will need to use this method. Stubs are one of the first steps towards getting your unit tests to pass, if you are following a test driven approach.

Mocks can be anywhere from a little more complex to a lot more complex than a stub. Mocks allow you to create methods/functions that return expected data. They are usually the next logical step in TDD after a stub. Building on the above stub a mock could be:

public static string SomeMethod(string MyString)
{
return "This is my new modified string";
}

This will get a test to pass and it will allow you to test other portions of your code that depend on this method without fully implementing it before you are ready.

Now where mocks really shine is when you start using interfaces. The way I use this is as follows.

public interface IStringManipulator
{
public static string SomeMethod(string MyString)
public static bool IsNull(string MyString)
}

Now that the interface is designed you can start with your mock.

public class mockStringManipulator : IStringManipulator
{
public static string SomeMethod(string MyString)
{
return "This is my new modified string";
}
public static bool IsNull(string MyString)
{
return true;
}
}

You have your mock, now you can use the mock as a placeholder.

public class WebConnector
{
public void Connection(string Username)
{
String NewUsername;
if(!mockStringManipulator.IsNull(Username))
{
NewUsername = mockStringManipulator.SomeMethod(Username)
return NewUsername;
}
else
{
throw NullReferenceException;
}

}
}

You will of course be writing unit tests on the WebConnector class and when you get around to fully implementing the StringManipulator class you will be using the IStringManipulator interface. This ensures that all the only difference between your mock class and your production class is in the implementation. The signatures and everything else matches exactly and since you will be performing TDD on the production class you will have a high degree of confidence that it will work as expected before you change from the mock to the fully developed class.

Thursday, July 24, 2008

Merging Datasets and Updating

After about 4 days of frustration I finally found out how to get this working.

I have a table in a database that I am looking to move to the same table in another database. This seems like an ideal solution for datasets and it is. If you follow the MSDN documentation I found it doesn't work. I have been pulling my hair out and researching datasets for 4 days now trying to figure out why it wouldn't work. When you view the dataset after performing the merge all the data is there and when you perform the update it doesn't error out or throw an exception, however, it didn't work.

What was comforting through this learning experience is that I was no the only one running into this issue. I found hundreds of posts from 2004 to present about this very same issue but not one solution, until today. Some of the seasoned .NET programmers probably already know why, but for those that are still learning I will tell you why.

When you create an adapter, any adapter, and fill your dataset, all rows will be marked as unchanged. This sounds reasonable since you haven't changed anything yet but when you are migrating data it will not work for you. The reason it doesn't work is when you call the update method on your adapter to move it to the new location the method is going to look for rows that are added, deleted, or changed. It is going to completely ignore the rows marked as unchanged. This I understood, what I couldn't figure out was how to mark those rows as changed without manually iterating through each row and making some change.

Enter William Ryan and his great article on "DataSet.Merge and Transferring Data". The way to get this to work is very simple, after you have set up your adapter and before you fill your dataset you need to set the AcceptChangesDuringFill property to false. The reason you set it to false is to get each row in the dataset to be marked as added. Then when you update it all the rows will be added.

I hope this helps some one out and big thanks to William for a great write up.

Wednesday, July 9, 2008

So many tools so little time.

I am still reading through the test-driven development book and am amazed by the number of tools/utilities that are available for Java. I am able to find some of these for C# but many don't have a counterpart in C#. I am starting to realize how serious of an undertaking practicing TDD is going to be for me. Just going through a mock/stub by hand is not easy, especially when you are just starting to create them. I do think it is a great exercise to improve your understanding of exactly what you are doing but I would not like doing it long term.

So far I am going have to learn, MbUnit, Rhino.Mock, Nester, NCover, and ReSharper, when I buy it. That is a lot to learn but in the end I will be much better off than where I started.

Tuesday, July 8, 2008

Testdriven.NET and Ad Hoc testing

Since I am fairly new to C# I still make a lot of syntactical mistakes. One of the features I love about Testdriven.NET is the ability to run Ad Hoc tests on a newly created method to make sure it will actually run. This is by no means a replacement for proper Unit Tests but it does at least tell me if I made a mistake with the code that would prevent it from building without going through the entire process of actually building it.

To run an Ad Hoc test add MbUnit as a reference to your current project.
Then create a method. Once the method is "complete" right click anywhere inside the method and select Run Test(s).

I am using the default setup for Visual Studio and Testdriven.NET. This will allow Testdriven.NET to show the output in the "output" pane.

3 months in

I have been teaching myself C# for about the last 3 months now. My background was in C and Assembly and sometime last year I picked up Python. Python was a lot of fun. I didn't need to understand much about OOP to get started and was still able to be functional from day 1.

C# hasn't been so easy. I purchased 2 books on learning C# from Apress, "Beginning C# 2008" and "Beginning Visual C# Express 2005". Knowing what I do now they are great books, however, coming from a C/Assembly background they did not allow me to learn the language. I feel the reason for this is limited exposure to OOP in these books. One of the books had 1 chapter on OOP while the other had 2. After reading both books I was frustrated, lost and thinking about ditching C# all together. That was when I decided to try a different approach.

I went out and purchased "The Object-Oriented Thought Process" by Matt Weisfeld. I have to say that this was the best thing I could have ever done to get a grasp on C# and OOP in general. Most of the code samples were in Java but C# is similar enough that I was able to follow along without getting lost. I learned a lot from this book and plan to reread it several more times to get a better grounding in OOP. It also opened up some new areas I didn't know about, UML for instance. For anyone coming from a procedural background I can't tell you how invaluable this book is.

I then went back and reread my previous 2 purchases and have been happy with the content. The Visual Studio book got me started on creating UIs for my apps, something I have never had a need for. The 2008 book taught me about writing tests for the code that you are writing. This was something new and after trying it out I felt it added alot to my learning ability. I even picked up a new book "Pro C# 2008 and the .NET Platform. This was definitely the next step in C# books for me. It was around this time that I began speaking with a co-worker of mine, Adron, about some of what I was working on. Talk about opening a can of worms.

Adron is one of those guys that if he couldn't do it he would be teaching. I am not talking about the boring lecture types but the one that gives real world concrete examples. He also has a ton of knowledge on process that I never had any exposure to. He starts throwing out terms like "Agile Programming", "Unit Testing", "Refactoring", "Design Patterns". I am just looking at him like he is speaking a foreign language, because he is. That was when he did something I hadn't expected, he gave a 5 minute brain dump of it all. Not everything mind you but enough to wet my appetite and show me why they were important. Now I was hungry again and off to the bookstore to find out what I could on these "new" processes.

So I take a look at all the books they have to offer and realize I am not going to dump $300 on the books I want so I prioritize the list of processes and Test Driven Development rises to the top. I felt that at this point I was going to get the most out of TDD. For some reason I couldn't find anything on TDD in C# but I did find the next best thing, TDD in Java using jUnit. Again Java is close enough to C# that I can follow along and jUnit is close enough to mbUnit as well. I purchased "test-driven development A Practical Guide" by David Astels. So far it has been an exceptional book. It has some minor coverage on refactoring and design patterns already in it. This is another highly recommended book.

The frustrations have been hard but the rewards are starting to pay off.

Some things that I would really like to see change is an improvement in the documentation surrounding mbUnit. I end up using the nUnit documentation to figure out where to start from then fill in the blanks. I suppose it is pretty smart to have another project providing your documentation but until Adron told me to look at the nUnit documentation I didn't even know the project existed. Here is a perfect example. Perform a google search on mbunit and exception assert. I didn't find an mbUnit page until the 44th entry. With nUnit it was the first entry returned.