Team – Roles – Common Platform
I keep seeing the same issue - every application that is built has a different platform. Within a given tribe, there may be a dozen applications each starting and ending using different patterns and practices. Different ways of handling authentication, authorization, pages and/or controls, AJAX, jQuery, ADO.net-MSFT data access application blocks, deep OO model – thin SOA. It goes on and on. Many following the best practices found in enterprise software development, many are good.
The biggest hurtle here is communication. It’s like speaking a dozen languages in a single tribe. For a recent project, one of my goals was to have all members speaking the same language; using the same patterns; using the same architecture for design; structure for controls and data access.
General Purpose Application Platform
Enter BlogEngine.net (BE.N); my favorite application platform. There, I said it. I host my blog on BE.N. In fact, I migrated many of my customers to BlogEngine.net and I use it to prototype ideas for new customers. How do I know I like it so much? Well, I use it to run my blog and I am constantly tinkering around with my site because I enjoy using BlogEngine.net so much. I use it for my research and currently have a distributed, parallel genetic algorithm solving complex multidimensional problems using Master-Slave architecture; where BE.N is the master and dozens of SOA clients as the slaves.
BlogEngine.net has all of the key pieces
Basic Idea
I decided to base the architecture for application implementation on the concept of pages. Most blog engines have two distinct types of content: pages and posts. Posts are the typical type of content that becomes part of your blogs feed whereas pages are usually static content which can be anything outside of a blog post (for example an 'About Me' page). BlogEngine.net already has everything I need to get the content of page created and persisted in a data store (it supports xml and SQL Server out of the box).
Pages are all dynamic. Idea here is to create controls to place on the dynamic pages. This has many benefits. It naturally divides the tasks into controls, objects, to/from data store; spread around the members on the team to reunite into a large application. Deployment, first time deploy all; thereafter, only deploy updated/new controls (see my post on deploy using single DLLs). Repeat. Keep inventory of controls for future projects.
Generate frame of the Controls
I use the Data Aquarium framework for many of my data administration tasks. Are you too busy to create admin screens? Have CodeOnTime generate them for you. In the theme of consistency, I found that using the code generator has many benefits; first being consistency. If all controls start from generated code (yes, the gen’d code is clean), tend to remain fairly consistent. This is another key element in keeping the tribe speaking the same language.
Pattern
Use BE.N as the platform. Use CodeOnTime Web Form Builder for building user controls, put them in the “User Controls” folder. Run your application, add the pages, add controls to the pages. Nice!
Sharing
Sharing best practices is another way to keep the team on a united front. Make sure you leave enough time in the week to share ideas, leverage improvements, and sync up.
I have a BE.N Aquarium Control in development, so stay tuned in for the release!
Thank You for listening.