Category Archives: Web Applications

Architecting A C# Web-Based Application: General Concepts

So, we’ve loosely tossed around our greenfield web application project in our head, and we’ve decided that we’re going to go ahead and develop it. The question then becomes “What’s next?”

At this point, the temptation is to just jump in and start coding, especially if the project is personal (not derived from one or more external stakeholders) and scratches a big, immediate itch. In my case, I have been trying to find a good PM solution that doesn’t burden me if umpteen keypresses to log tickets and has a real ability to workflow items. Many do not fit the bill, and my workload isn’t getting any leaner.

But, instead of jumping right in, we’ll pause for just a little while, and gather up some key concepts we want to put in play in this project. There are a lot of choices to make when you develop a web application. There are concerns over technologies (ex: databasing both relational or KV store, code repositories, etc.), libraries (ex: ORMs, serializers, etc.), platforms (ex: ASP.NET MVC 2), frameworks (ex: jQuery, Sharp Architecture, etc.), development methodologies (ex: TDD, BDD), management approaches (ex: Scrum, XP), architecture concepts and patterns (ex: CQRS, DDD), amongst many others. While each one of these items, like CQRS, is often the subject of multiple blog posts, but I will attempt to cover the salient items with respect to this project within a couple of posts.

In this project, we will cover:

  • Domain-Driven Design (DDD): Domain-driven design has been around for a decade or two, but has really taken off in the last few years, as more developers start tackling software of growing complexity. DDD is a methodology (as in “a framework that is used to structure, plan, and control the process of developing an information system”) that addresses the broad topic of researching, understanding and then designing the conceptual part of whole systems. DDD makes the developer focus on the core functionality by isolating it into a domain model, separate from other concerns, and also by bringing the developer closer to the business user’s language. It does this through the core concepts of “ubiquitous language” and “bounded contexts”, which we will discuss in a later article. The goal of DDD is to create a set of techniques, concepts, patterns and language that directs you to focus on the domain, on the concepts of the system, rather than on the underlying technologies. Said differently, if you want to produce good software, it is more critical that you understand what an Order is and does logically, rather than decide which NoSQL store du jour to use. The latter is often more exciting to technologists, and is also a case of putting the cart before the horse. DDD will help not only build better software through better focus, but also help us do simple things like give us direction in project structure.
  • Command Query Responsibility Segregation (CQRS): This is actually a simple architectural concept or pattern, rather than a comprehensive, technology-specific framework or methodology. The goal is implied in the name itself. The idea is that commands/actions that tell a system what to do and that change the state of the system are segregated, at least logically, from the act of querying the state of the system. Reads and writes frequently contend in busy systems. CQRS is an approach to mitigate that reality of system design. Again, we’ll explore this in its own article soon.
  • Event-Based Architecture (EDA): The ever-present question in any developer’s mind at work is “Where should this block of code go? How should I organize my code?” We want the end-product of our craft to be easy to write, easy to read and easy to change. These needs are encapsulated by a lot of acronyms: DRY, GRASP, SOLID, etc. In very general terms, the main goal is low coupling (low dependencies between functional sections of code, classes or otherwise) and high cohesion (breaking down code into functional sections that are very focused in purpose). Of course, as you break down your code into focused chunks that are independent of each other, the question becomes how do you get them to work together? In comes messaging. These blocks of code coordinate and affect each other via messages. One block of code raises an event (a message) that it did its thing and changed the system, and then interested listeners pick up the message and do what they were created to do in response.
  • Dependency Injection (DI): When we create blocks of independent code, oftentimes there is the need (or temptation) to have one block use another block directly. And so, we pull a direct reference or link to that code; we new up what we need. In so doing, we have increasing the amount of coupling in the system. DI is a way to reduce this coupling. For example, if we implement an EDA-based system, almost every block of code needs to publish their event messages into a system that can then distribute it out to interested listeners. We don’t want to have that code in multiple places; that breaks DRY. We also don’t want to put that code in its own block, and then have every other block link to it; that ruins low coupling. Instead, we use the DI pattern. This allows us to register the event system, and its various parts, in a container or directory that any other part of the system can see and use. That code doesn’t get repeated and the indirect nature of the link allows looser coupling. So, when one block of code needs an event publisher in our EDA system, it calls for one generically (“Hey I need an object that has a way to let me publish an event into the message bus!”) and gets whatever is registered in the system (“Here’s an concrete object for you to do this. It has the method you need.”). Basically, you let a specific part of the system focus on managing dependencies, instead of the immediate code doing it for itself. That makes it easy to change parts. Is your custom-built publish-subscribe code not robust enough? Well, plug in NServiceBus. Built right, with the blocks of code offering up the same interface to achieve the same functions, you should be able to swap systems out.
  • Aspect-Oriented Programming (AOP): AOP is a programming paradigm, a style of coding. The keyword, aspect, describes a focused functional block of code that has a high amount of reuse throughout a system. Aspects are these blocks that are cross-cutting concerns because they “cut across” (a.k.a. “are used in”) many different blocks of unrelated code in the system. A classic example of an aspect is the need for a logging subsystem in an application to support debugging efforts. In a way, whereas DI is a passive way to allow one block of code to use another, AOP is much more active and/or broad-stroked. AOP prescribes a way to apply a block of code (a.k.a. advice, ex: “run this aspect before the block”) across some or all blocks of code (a.k.a. cut points, ex: “all methods in namespace X.Y.Z”). Aspects are a great way to keep such code in one place for maintainability, but effectively apply it where necessary with low cohesion, since the affected block is effectively oblivious to its presence.

We’ll explore a lot of these concepts in detail in subsequent articles. And, I reserve the right to expand this overview list as I discover more topics that deserve an “executive summary” for those fresh to the series. For example, I have not covered testing, continuous integration, and other more technical items that add to our ability to deliver good software. If you think we should cover anything else, feel free to chime in.

Advertisements

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.

MachineKey Key Generator

It’s not super-easy to find a versatile key generator for creating truly random keys to use in your MachineKey section in web.config or machine.config. So, here’s a quick console app, and related zipped project (Current extension is .doc to bypass WordPress’ file type limitations. Just save locally using “Save Link As..”, rename extension to .zip, unzip and enjoy.) to help you out with generating any of the various allowable keys you may need. Run it from inside a command-line window by calling:

MachineKeyGeneratorConsole.exe /v:<insert validation key type> /d:<insert decryption key type>

To save to a file, just type:

MachineKeyGeneratorConsole.exe /v:<insert validation key type> /d:<insert decryption key type> > key.txt

The switches are optional. Valid values for validation key generation are: AES, AES128, AES192, AES256, MD5, SHA1, HMACSHA1, SHA256, HMACSHA256, SHA384, HMACSHA384, SHA512, HMACSHA512. If no value is given, the default value is SHA1. Furthermore, although you can give different key sizes for some algorithms, the appropriate MachineKeyValidation is returned.

Valid values for decryption keys are: AES, AES128, AES192, AES256, DES, 3DES. If no value is given, the default value is AES.

using System;
using System.Diagnostics;
using System.Linq;
using System.Security;
using System.Security.Cryptography;
using System.Text;

namespace MachineKeyGeneratorConsole
{
    static class Program
    {
        static int Main(string[] args)
        {
            if (args.Any(arg =&gt; arg.ToLower().Equals("/t") || arg.ToLower().Equals("-t")))
                Trace.Listeners.Add(new ConsoleTraceListener(true));

            try
            {
                Run(args);
                return Environment.ExitCode;
            }
            catch (Exception e)
            {
                Console.Error.WriteLine(e.Message);
                Trace.TraceError(e.ToString());

                return (Environment.ExitCode != 0) ? Environment.ExitCode : 100;
            }
        }
        
        static void Run(string[] args)
        {
            int vkeybits = 256;
            string vkeyalg = "HMACSHA256";
            string vchoice = args.FirstOrDefault(arg =&gt; (arg.ToLower().Substring(0, 3).Equals("/v:") || arg.ToLower().Substring(0, 3).Equals("-v:")));
            if (vchoice != null)
            {
                Console.WriteLine("Requesting validation key: " + vchoice.Substring(3).ToUpper());
                switch (vchoice.Substring(3).ToUpper())
                {
                    case "AES128":
                        vkeybits = 128;
                        vkeyalg = "AES";
                        break;
                    case "AES":
                    case "AES192":
                        vkeybits = 192;
                        vkeyalg = "AES";
                        break;
                    case "AES256":
                        vkeybits = 256;
                        vkeyalg = "AES";
                        break;
                    case "MD5":
                        vkeybits = 128;
                        vkeyalg = "MD5";
                        break;
                    case "SHA1":
                    case "HMACSHA1":
                        vkeybits = 160;
                        vkeyalg = "SHA1";
                        break;
                    case "3DES":
                        vkeybits = 192;
                        vkeyalg = "3DES";
                        break;
                    case "SHA256":
                    case "HMACSHA256":
                        vkeybits = 256;
                        vkeyalg = "HMACSHA256";
                        break;
                    case "SHA384":
                    case "HMACSHA384":
                        vkeybits = 384;
                        vkeyalg = "HMACSHA384";
                        break;
                    case "SHA512":
                    case "HMACSHA512":
                        vkeybits = 512;
                        vkeyalg = "HMACSHA512";
                        break;
                    default:
                        vkeybits = 160;
                        vkeyalg = "SHA1";
                        break;
                }
            }

            int dkeybits = 192;
            string dkeyalg = "AES";
            string dchoice = args.FirstOrDefault(arg =&gt; (arg.ToLower().Substring(0, 3).Equals("/d:") || arg.ToLower().Substring(0, 3).Equals("-d:")));
            if (dchoice != null)
            {
                Console.WriteLine("Requesting decryption key: " + dchoice.Substring(3).ToUpper()); 
                switch (dchoice.Substring(3).ToUpper())
                {
                    case "AES128":
                        dkeybits = 128;
                        dkeyalg = "AES";
                        break;
                    case "AES":
                    case "AES192":
                        dkeybits = 192;
                        dkeyalg = "AES";
                        break;
                    case "AES256":
                        dkeybits = 256;
                        dkeyalg = "AES";
                        break;
                    case "3DES":
                        dkeybits = 192;
                        dkeyalg = "3DES";
                        break;
                    case "DES":
                        dkeybits = 64;
                        dkeyalg = "DES";
                        break;
                    default:
                        dkeybits = 192;
                        dkeyalg = "AES";
                        break;
                }
            }


            StringBuilder section = new StringBuilder();
            string vkey = GetRandomKey(vkeybits/8); // SHA
            string dkey = GetRandomKey(dkeybits/8); // AES can be 32, 48 or 64 chars, DES is 16 chars, 3DES is 48 chars
            section.AppendLine("");
            Console.WriteLine(section.ToString());

        }

        static string GetRandomKey(int bytelength)
        {
            int len = bytelength * 2;
            byte[] buff = new byte[bytelength];
            RNGCryptoServiceProvider rng = new RNGCryptoServiceProvider();

            rng.GetBytes(buff);

            StringBuilder sb = new StringBuilder(len);
            for (int i = 0; i &lt; buff.Length; i++)
                sb.Append(string.Format(&quot;{0:X2}&quot;, buff[i]));
            return sb.ToString();
        }
    }
}