Tag Archives: c#

Architecting A C# Web-Based Application: Introduction

I am beginning a series of articles on architecting a “serious business” web-focused application. The raison d’ĂȘtre for this is because I have been unable to find a focused, well-documented sample project that exposes practical architecture and guidelines. The overall goal is to put myself on the line as a guinea pig, journal my thought process at every step, take the abuse and, hopefully, generate some positive discussion on the choices I make along the way. The secondary goal is to provide intermediate developers an example of how to approach a common type of project. As such, the series will not be an exploration of cutting-edge technologies, or of advanced coding techniques.

The sample application will be a project management application that follows the great majority of the basic Scrum principles, allows a development team to better manage their workload, and also maximizes the offload of data entry and organizing to the stakeholders as much as possible. I know that this type of application exists in umpteen forms on the net. Let’s face it, it’s basically the “enterprisey” equivalent of Tetris. However, I selected it for three main reasons:

  • The project is a neither too complex, nor uselessly simple in scope
  • It is a domain that should not be foreign to a readership composed of developers
  • I need a good app that fits the way my team works, rather than the overly generic and bloated PM software out there. While this may seem selfish, it’s actually good! I’ll be eating my own dogfood.

I think many developers don’t enjoy the use of most of the PM software out there because they become responsible for too much maintenance/clerical work. Not many packages out there put as much responsibility for the project in the hands of the stakeholders, and if they do, invariably they charge for more licenses. We’ll start simple, focus on providing a great UI, and won’t involve feature-creep just to gain bullet points on a sales presentation. Ultimately, the code base will be provided at large as an open-source project.

The whole solution will consist of your typical moving parts:

  • A web-based client where the majority of the interaction with the system is done, especially the collaborative parts.
  • A task bar application that allows quick data entry, primarily by developers, for common functions.
  • A middle layer built to handle the above two clients, and open for more. This will be where all the rules, workflows, transformations and other tasks happen. This will also force one to consider how to build the layers.
  • The database layer, obviously used to persist data.

The minimal functionality we will provide for a “v1.0” is:

  • The ability to work with the four general “things” found in Scrum: roles, timeboxes, artifacts and rules.
  • Allow business users to easily log ideas (a.k.a. user stories) and track the status thereof.
  • A robust and customizable workflow system for managing rules that, while not very dynamic, should be open to some amount of customization.
  • Some dashboarding for some simple metrics.
  • While we won’t aim to provide a full interactivity suite, it would be nice to build in a way to have a threaded discussion area for each idea or story, such that devs and users can collaborate and flesh out ideas in a way that doesn’t create an email nightmare.
  • A cross-platform, browser-based user interface with a form-based authentication system.
  • Optionally integrate logins with AD or other LDAP system.
  • A small taskbar application that helps you track what you are currently working on and gives feedback on changes in the app.

As you can see, this is not a simple throw-away project. But, neither is it a highly-complex, enterprise application. I hope that this series can help junior and intermediate .NET developers get a feel for how to approach the design of a web application, elevate my own game through feedback both high and low, and for intermediate to senior developers to collaborate on different approaches effectively by having the constraint of a defined scope in play. (Lots of times, comments on blogs like this run the gamut because some people are thinking of more complex projects than others.)

The next articles will cover the typical questions you (should?) have when you kick of a project:

  • What exactly am I talking about? Let’s spend some time on some diagramming and scoping to understand the larger moving parts. We’ll obviously iterate and refactor to get it right along the way, and so let’s not paralyze ourselves early, but we do need to establish some common language between the participants.
  • What tools am I going to use? For example, what framework will we use to get data in and out of our application? And, why? Another example is the many forms of IoC containers out there. Which one and why?
  • How am I going to structure all this practically? Let’s talk about overarching principles/methodologies that we will choose to apply on this project. Let’s also establish the subprojects in the overall solution from a technical standpoint.

Please, if you have any suggestions or comments, serve them up now! Especially if there’s anything in particular, top-level, that you think should be included. And, I hope you join me actively in subsequent posts.

Silly C# Dictionary Error

So, I stumbled across an interesting error while coding today, which in hindsight is really simple (less tactful and more self-deprecating would be to say “stupid”). In C# (3.0), there is a set of classes that supply you with some really common generic data structures, such as the Stack or the Queue. Using generics, you specify the type(s) such that you can have handy, type-safe collections to work with.

In a small bit of code, I was making use of the Dictionary, more specifically Dictionary. I was first filling it with keys only, which corresponded to specific pages in a large PDF. I then iterated (foreach) through said Dictionary a second time, chopping up the large PDF based on the indexed pages, creating smaller ones, and putting the resultant file name in the value part of the KeyValuePair. Many times, we fill and iterate in a read-only way with the structures, so this error is uncommon if you forget something basic about them.

When first stepping through my code, on the second foreach block, I got a “Collection was modified; enumeration operation may not execute.” Wha? I had forgotten that you will get this error if any reference in the Dictionary gets changed to a new reference. IOW, if you take an instance of a class that is stored in the Dictionary and replace it with a different one, while looping, the IEnumerator notices the change and chokes on the “dirty” collection.

You are allowed to change the properties of objects stored in your collection, though. So, a simple fix is that instead of using a string, which is immutable, and doing something like:

Dictionary pageDictionary<int,string> = new Dictionary();
...
for (int i = 1; i <= theDoc.PageCount; i++)  // first loop
{
  pageDictionary.Add(theDoc.PageNumber, "")
}
...
foreach (KeyValuePair<int,string> idxPair in pageDictionary)  // second loop
{
  pageDictionary[pageIndex] = extractFileName;
}

You should use StringBuilder, which is like String, but mutable:

Dictionary pageDictionary<int,StringBuilder> = new Dictionary();
...
for (int i = 1; i <= theDoc.PageCount; i++)  // first loop
{
  pageDictionary.Add(theDoc.PageNumber, "")
}
...
foreach (KeyValuePair<int,StringBuilder> idxPair in pageDictionary)  // second loop
{
  pageDictionary[pageIndex].Append(extractFileName);
}

Duh. Silly me.