Windows Programming / C#
When I posted my schedule for the semester on Facebook, one of my friends exclaimed, "'Windows programming'? Is that a history course?"
Well, this is another case of a course in search of a better title. We weren't really learning programming for Windows so much as we were learning to do some desktop-application stuff in C#, for the .NET Framework, which in turn runs on Windows. I'm a fan of .NET but writing applications for it is not nearly the same thing as writing directly for Windows. But the good part about writing for .NET is that someone can cook up another implementation, for example Mono on Linux, and you can bring your stuff over there (at least that's the vision).
We started off by porting our Dungeons and Dragons projects from Java to C#, which was a good way to see first-hand the similarities and differences. (I didn't implement multithreading and delegates, though, because I hadn't yet been trained how to use them. I didn't know how to use them in Java, either, but I didn't let a silly thing like that stop me.) Most of the rest of the course was integrated with our Capstone project, except for an individual examination at the end.
Okay, so how do I explain what the exam was about? We started with a single table of records... well, we had to make the table and the records. Then we set up a data access "program" (well, a library) capable of connecting to, executing commands on, and returning result sets from this database. On top of that, we wrote a business layer, a go-fer that translated between a pure entity class (think "Hi, I’m newStudent, a Student! My name is 'Bob!'") and the database (think database stuff like a name column in a Students table). Finally, on top of all that, there was a desktop application that wrote and saved in pure entity terms, without any idea of what the database was. Architecture!
Oh, and then we built a web service to return the pure entities in XML, a plain-text markup language used for information exchange. This was a lot easier than it sounds. Then we made a quick-and-dirty website to consume this webservice and display these records. Again, fairly easy – if you know what you’re doing.
The instructor released a practice exam with the same specifications, but on a different entity (like, say, Questions instead of Students). So for that reason I don't feel like I'm betraying the system by providing information here. Anyway, I completed the practice exam to its full specifications. And the real thing still took me four-and-a-half hours!
I could have done this project in half the time – or less! – if we'd been allowed to use LINQ to SQL. It can do all the business layer stuff we did manually automatically and reliably. There’s no reason not to use it (for those who might wonder, yes, you can use stored procedures, and it's a snap). LINQ is relatively new, coming to .NET in 2007. (There's also the more complex Entity Framework that can even build a database that fits your application code, but for this it would have been overkill.)
So one of my friends taught me how to do all the database stuff manually. Without him, I would have been up the creek. In the end, I guess it was a pretty decent learning experience, if a bit jarring and last-minute because most of us had never needed to do the translation stuff manually (at least not between SQL Server and a .NET app), except for this exam.
Writing object-relational mapping stuff yourself is becoming the programming equivalent of churning your own butter. So I guess this was a history course.
|2013, William Matheson|