In a nutshell: We got into groups and held meetings with a (pretend) client to glean the requirements of a project, we wasted a few weeks on diagrams and use cases, and then we ignored the diagrams and use cases and delivered the project. I worked with Jamal Rahhali, Brandon Richard, Richard Sayat, and Alan Smithee.
The centerpiece of this course was a desktop application that would automate the procedures of the client's ordering and manufacturing departments. Later, those in the ASP.NET course built an e-Commerce website for the client. The whole kit and caboodle is in the download (see below).
The good news is that we got the desktop application sort of working. It was far, far, far from perfect. Sure, "perfect" is a line you can never ever quite reach, but we were, it's safe to say, measurably far from it.
If I were doing this again, I would have banged out the database manually instead of trying to use the Entity Framework. We probably weren't using it properly and, among other things, we ended up with a bunch of duplicate foreign keys* in the database.
This was a difficult project to manage for several reasons: first, if one person needed to make a change to the database, that change would have to be mimicked in everyone else's environments. Worse, the desktop application, tabbed though it was, was all in two classes – manufacturing and ordering, so you were always hanging around in the same scope as the tabs your teammates were working on - this might have worked if we were better coordinated! You also had to think about when to load your data so that yours wouldn't get out of sync because of something a user might do in another tab. As always, the wonderful Index out of Range Exception** was the bane of our existence.
After the desktop application was "finished", we turned our attention to the e-Commerce website. A user can register for the site, then the admin will figure out which client account the user is associated with, make that association on the back-end site, and then the new user can sign in to place orders, view their order history, and manage client contacts. The security is role-based: this user is an admin, this user is a registered user, this user is a new user... and the role determines what pages can be accessed and also the links that they see in the navigation menu.
I started coding from the back-end and my teammate started from the front, and we had our Great Moment™ when he made a user submit an order (the checkout was the last thing he made) and we saw that order appear on the order history page (the history page was the last thing I made). It was like the English and French meeting under the Channel.
* - Picture a table of Students. Students are registered to one and only one Campus, so there'd be a Campus_ID foreign key in the Students table. In it is the record number of the Student's corresponding Campus in the Campus table. Our use of the Entity Framework was mucked up enough that we had the equivalent of a "Campus_ID", but also a "Campus_Campus_ID", both containing the same record number.
** - This happens when you try to do something at an index/position of an array or list that doesn't exist yet. For example, here is a zero-indexed list, let's call it myList: 1 3 5. If I do this: myList + myList, that’s 1 + 5, so I get 6. If I do this: myList + myList, the computer explodes and everybody dies.
|2013, William Matheson|