So, I did it! I finally did it!

I wanted to publish my ideas for a framework, and I did. You can find it on CodePlex at http://www.codeplex.com/aspnetmvp.

Go have a look. I really want to know what you think.

Now, I know there are a million and one frameworks for the web, so I don’t intend on trying to make anything big out of this. But I also know that my customers, usually decent developers with basic ASP.Net knowledge, are constantly asking me for guidance for creating ASP.Net projects. To avoid repeating myself over and over, this project gives them a good starting point. When something better comes along, I can point them to that instead.

I can also use the project as a place for creating new ideas, like

• WF integration and reusable workflows, like shopping carts or the “hub and spoke UI pattern”.
• plug-ins and skins, like Dotnetnuke

I definitely do not want to reinvent the wheel. But I believe that there are currently loads of great ideas which could be used in a framework, but just require a little bit of effort to make them simple to use (e.g. UrlRewriting). Most of the developers I know want those extra features without having to spend a lot of time learning a new technology. This framework should be for them.

Instead of totally turning the heads of such developers around, asking them to use a completely new system (e.g. the ASP.Net MVC framework), this framework is meant to provide helpful stuff without stopping you from doing things the way you want (favicons and robots.txt files, for example). It gives you guidance on where to put your CSS files, master pages, scripts, and images. It also provides a way to do testing and project management in a sensible and flexible way. It uses the MVP pattern, but that isn’t mandatory. You can still write code in webforms if you really want to, and then you can refactor them out quite easily later.

I based my MVP implementation on some of the code from the Microsoft Patterns and Practices Web Client Software Factory. However, they made extensive use of the ObjectBuilder and attributes, which I found to be overengineering and too complex. So, as an alternative, I recreated the ideas using generics. I found it works well, and doesn’t have the performance overhead or the learning curve required with WCS.

The code currently uses the AdventureWorks Database, which you will need to install first before using the code. You can find the database on CodePlex here.

I’m currently working on another top-secret project, so I won’t really be spending much time on this. If you’re interested in discussing ideas or doing something with the project, let me know. I’d love to hear what you have to offer.

Otherwise, head on over to the ASP.Net MVP Framework site, and check out the code.

Oh, and until the lawyers call and ask me to change the name, let’s just leave it as it is.

P.S. I forgot to mention a “feature”. The Yahoo UI Framework has some great stuff for CSS, including grid layouts and css reset files. I integrated that too. I put it in the default theme. It means you don’t have to do much work to get your stylesheets to lay out your webpages well.

More to come on that later.

DotNetRocks, the internet talkshow for .Net developers, has a great show about development changes over the past 20 years. Carl Franklin interviews Kathleen Dollard, who has put a list of changes together, and is publishing them online.

If you want to know where you currently stand in your software development, you want to listen to this show. You might even want to take notes.

If you are recruiting developers, you also should listen to this show. You could use very effectively it to find out what kind of people you are interviewing.

The first 10 of 60 items on Kathleen’s list of changes are:

1. Parallel entities
2. N-Tier
3. Sheer magnitude
4. Application code generation
5. SOA (Service Oriented Architecture)
6. Semantics and canonical messages
7. Workflow
8. Rules engines
9. Aspect oriented programming
10. Impact of libraries

Every software developer or architect should know at least a little about each item on this list. If you don’t, maybe you could use this to pull your career up a level.

I’m often asked to produce design documents for new applications. I can’t do this without discussing the advantages and disadvantages to each part of the design. A great way to do this is to focus on the desired qualities of the system you’re trying to build. Define the qualities you are trying to achieve, and design each part of the system to match those qualities as best as possible.

It helps to have a list of things to consider. Here’s a list of some of the qualities you need to address for a .typical Net application:

Development-Time Qualities

• Modifiability – (Often called “flexibility“, and especially important for agile development.) How easily can the software be modified to additional requirements and changes? Can changes be localized to as little code as possible? Do public interfaces have to change? How are the parts of the application dependent on one another? Are the most-likely-to-change areas of the application depended upon to be stable? To what extent are concerns separated?
• Reusability – Can units of the application be reused elsewhere? Does the code fit the “DRY” principle (Don’t Repeat Yourself)? Does the system make good use of existing standards? Reusing code from other frameworks and systems can help keep testing and maintenance down, but reduce modifiability.
• Portability – Could the system be easily ported to other platforms? This is often not an issue for most enterprise applications, as business requirements typically change more frequently than the technical platforms, and the .Net framework takes care of most of the issues. For a web application, portability could also include browser compatibility. What happens if the users suddenly receive an upgrade to their browsers?
• Testability – How easy is it to prove that the application functions correctly, and that the various parts of the application do what they are supposed to do in isolation of one another? Can the application be tested automatically? Can the application eventually be tested easily end-to-end as part of an integration test? Can the application be load-tested?
• Buildability – Can the application be built on systems other than those in the development environment? How often can it be built? The more often it can be built, the better. What tools can be used to do the builds? Can they implement continuous integration by building at every check-in? Which third-party controls or components are used? What part do licenses for third-party products play in the ability to build centrally?
• Maintainability – How easy is it to understand the software for people other than the original developers? How easy is it to correct defects? Is the system documented enough to make it understandable?
• Debugability – How easy is it to find out where and why there is an error in the system? How easy is it to find what is going wrong in a live, productive system?
• Extensibility – How easy is it to extend the functionality of the system beyond its original specification?

Runtime Qualities

• Functionality – How well does the software help the users to do their work? Are there missing features which make the software useless? Does the software provide end-to-end support for a particular process?
• Usability – How easy is it for users to understand and learn to use the software?  Is the interface intuitive? Is there a supportive help system? Does the user interface match the users’ needs? Are basic usability standards and conventions adhered to?
• Performance – Does the system perform fast enough? How does it perform when multiple users are active? Where are the bottlenecks and latency in the system?
• Concurrency – Is it possible for more than one user to use the system at a time? What is the performance impact of multiple sessions? Is state shared across the application, making the system unreliable?
• Security – Does the system prevent unauthorized access or misuse? What happens if access is wrongly denied to a user? How easy can security be administrated? Does the STRIDE threat model show up any weaknesses? What is the potential outcome of a successful attack? 
• Integrity – This can be related to security, but it also refers to the data integrity of the system. Is the data always kept in a consistent state, or is it sometimes possible to infer different states of the system because of inconsistencies in the system? Do transactions pass the ACID test?
• Reliability – Can the users rely on the software? Will it always perform correctly? Is it still usable at peak usage periods?
• Availability – How often and for how long is the system available for use? How do upgrades affect its availability? Is the system meant to be used across time-zones?
• Scalability – How does the software cope with adding more users over time? Can the system cope with an increase in the volume of data? What happens if the users start to use the system more often? Must the software scale up or can it scale out?
• Deployability – How easy is it to deploy the initial release of the software? How easy is it to release future releases? Does software need to be replaced, or just patched? How does the deployment affect scalability?
• Ugradability – Can a new version be deployed without stopping the normal operation of the system? What must be changed or upgraded when a new version is released? What third-party software may be upgraded which would affect the software?
• Correctness – Does the software do exactly what was specified?
• Conceptual Integrity – How balanced, simple, elegant, and practical is the whole system? Is there a clear vision as to what the software should do? Is the design consistent?
• User Responsiveness – Related to performance and usability; how does the user perceive the application to be responding? Does the system stop responding for long periods of time, especially when retrieving data? Does the latency of parts of the system lead to decreased usability? Does the software use multiple threads to improve responsiveness?
• Interoperability – How easily can the system be used with other systems?
• Robustness – How does the system react to abnormal conditions? Does it crash, or recover gracefully? Do error messages baffle users and decrease usability?

Priorities

Software qualities must always be balanced against one another. There’s no point in having performance good enough for MySpace.com if it’s not needed, for example, especially if it makes maintenance harder. Each quality has a particular importance for the system being developed.

In general the highest priority qualities are:

• Maintainability
• Correctness
• Reliability

Also important for .Net Object-Oriented design are:

• Reusability
• Extensibility

Most of what I focus on in my day-to-day work is focused on good maintainability and modifiability. Changes come along all the time, and the people paying for the software want them done fast. The faster you can adapt to their needs, the more they trust you, and the better your business relationship.