At the moment, I'm working on a Silverlight project. The best way to learn a technology is to build something in it. Reading books and blogs and the rest will give you a vibe for what the technology is but only getting your hands dirty will make it real. Real is when you understand the beast and all its tides and moods. You also get to know the elegance of it and where the shine in its soul radiates from. Yes, I'm still talking about Silverlight.
One of the simple tasks in this current project requires me to parse a CSV file. That's easy enough to write on your own but anyone who has written a parser knows that if someone else has built one that does what you want then you should consume theirs. They would have handled all the exceptions and possible gotch-yas. This means I don't have to worry about that and I can get the task done quickly.
In this case, Fast CSV is a common choice in the .NET world. I've used it in the past on and it does what it promises. With the MIT license, the price is right too.
Sounds easy right? Well not totally. For my Silverlight application to consume this library, it must be a compiled as a SIlverlight library. Easy enough - I'll port it. Thing is, this code extensively uses the System.Data namespace and as I found out quickyly, there will be no talking directly to a database from a Silverlight application. That makes complete sense.
After looking in to it, the main use of System.Data is in the use of the IDataReader to stream the CSV file. There is also some DataTable usage. Nothing that couldn't be wrangled to use another stream reader and a generalised Linq table, in it's place.
But then I stopped...
When is porting the library more trouble than it is worth? My task is such a small simple one that I might as well write a custom parser that takes each line of the CSV file that I'm reading via normal file IO and push it straight to my view models for display.
Robustness of the code is an issue but I'll test drive it and keep it simple and neat. It doesn't have to be so general that it caters for every possible situation. It is just for my situation.
In this case, I have decided that a quick CSV parser that exists as a helper class in my project is good enough for this task. It is not just good enough but it's the right choice. Get the job done in a thorough way but don't over engineer the solution because it is the funnest way.
This has been a good learning experience and has solidified my resolve that sometimes you can write code that isn't so gold-plated and generalised and that's ok.
3 comments:
Have you looked at something like the ExtensionMethod site? It's a community site for submitting commonly-used extension methods for C#, and there are more than one for parsing CSVs (e.g. http://www.extensionmethod.net/Details.aspx?ID=165)
A useful concept and word here is "overengineering". It is just as unprofessional to overengineer something as it is to underengineer it. Why? Because it entails an unnessary cost in programmer time.
Oh. I see you alreay used the word "overengineering" :) I should read more carefully. Anyway, one of the duties of a professional developer is to reduce costs. Both under- and overengineering will increase costs.
Post a Comment