Intelligent Design : .NET

A Little Christmas Coding Magic

FTProductDev — Thu, 13 Dec 2007 07:01:00 GMT

When I was a kid I loved magic - simple card tricks to Copperfield’s million dollar illusions, I was easily mesmerized and mystified. People have been bending what we THINK is reality for years. Take a look at the picture - Which way does this window face. Are the people on the inside looking to the left or looking to the right? Are you looking up into the window, or are you looking down into the window?

Same thing goes for programming – what we type out in code does not always translate to "what is" during execution; especially if you’re dealing with a compiler between what you write and assembled code delivered into production.

Take the battle between a couple of conditional processing structures provided in C# (and most other languages): Who’s “better” regarding efficiency and elegance - a switch (case) statement or If-Else conditional statement. The GoOracle would tell you this is a no brainer, and logically we would assume that switch would perform better because the framework does not have to evaluate each statement in the flow.

Let’s assume otherwise and challenge the norm given the following code in pre-compiled form:

private static void SwitchSingleCondition() {

Stopwatch timer = new Stopwatch();

timer.Start(); // Start the timer

string compare = "a";

for (long i = 1; i <= 10000; i++) {

switch (compare) {

case "a":

compare = "b";

break;

case "b":

compare = "a";

break;

default:

compare = "a";

break;

}

timer.Stop(); // Stop the timer

Console.WriteLine("Execution time for 'Switch Single Condition' was {0:F1} microseconds.", (decimal)timer.Elapsed.Ticks / 10M);

}

private static void IfSingleCondition() {

Stopwatch timer = new Stopwatch();

timer.Start(); // Start the timer

string compare = "a";

for (long i = 1; i <= 10000; i++) {

if (compare == "a") {

compare = "b";

} else if (compare == "b") {

compare = "a";

} else {

compare = "a";

}

timer.Stop(); // Stop the timer

Console.WriteLine("Execution time for 'If Single Condition' was {0:F1} microseconds.", (decimal)timer.Elapsed.Ticks / 10M);

}

When executed we get the following results:

Why did the “if statement” run more efficiently than the switch? Let’s pull back the curtain and take away the mirrors – this is what the code looks like after compilation (Reflector you rock!):

private static void SwitchSingleCondition()

{

Stopwatch timer = new Stopwatch();

timer.Start();

string compare = "a";

for (long i = 1L; i <= 0x2710L; i += 1L) {

string CS$0$0000 = compare;

if (CS$0$0000 == null) {

goto Label_004B;

}

if (!(CS$0$0000 == "a")){

if (CS$0$0000 == "b"){

goto Label_0043;

}

goto Label_004B;

}

compare = "b";

continue;

Label_0043:

compare = "a";

continue;

Label_004B:

compare = "a";

}

timer.Stop();

decimal CS$0$0000 = timer.Elapsed.Ticks / 10M;

Console.WriteLine("Execution time for 'Switch Single Condition' was {0:F1} microseconds.", CS$0$0000);}

private static void IfSingleCondition()

{

Stopwatch timer = new Stopwatch();

timer.Start();

string compare = "a";

for (long i = 1L; i <= 0x2710L; i += 1L) {

if (compare == "a"){

compare = "b";

}

else if (compare == "b"){

compare = "a";

}

Else {

compare = "a";

}

timer.Stop();

decimal CS$0$0000 = timer.Elapsed.Ticks / 10M;

Console.WriteLine("Execution time for 'If Single Condition' was {0:F1} microseconds.", CS$0$0000);

}

Are you kidding me – the “if” logic even looks more elegant! So what happened? It seems that behind the smoke, mirrors, and assumptions the .NET framework looks at the code that was written and restructures it to what it thinks will be more efficient using if-else conditions, “goto” statements, and a labeling system. Once your case statement exceeds 4 conditions the compiler will leave the code alone and execute it as a normal switch case.

It turns out that if-else-if statements can and most likely will be more efficient than switch statements when the number conditions do not exceed four. Things aren't always what they seem. Don’t be blinded by the magic – challenge your assumptions - until they become fact.

--nick

Asp.Net vs. Standards

mvasquez — Fri, 02 Feb 2007 23:29:00 GMT

A few months back I converted our site template from a table-based layout to a standards based design. This was not a trivial task, in essence I "touched" every page in our app, which is more than 300 pages. Recently we released major pieces of functionality, both using standards based html and heavy client-side functionality (ajax via prototype, effects/drag drop via scriptaculous). For the entirety of the project I was in a constant struggle with asp.net and it's blatant disregard for supporting standards based design and HTML standards in general. Listed below are the issues that drove me to the edge of insanity, almost to the point of shunning off asp.net forever.

INamingContainer

I understand the need to uniquely identify objects in the control tree. But why does that id have to be persisted to the client? How are you suppose to get a reference to an element in css or javascript if you can't rely on the id? I've got an idea, stop trying to hold my hand and let me be responsible for uniquely identifying my controls. This leads to abusing the class attribute and using it where it simply should not be needed.

One form per page with runat="server"

I've been told that this has since been addressed in 2.0. In 1.1 this is unacceptable, for instance, in our site template we have a drop down within our sub navigation (don't ask me why it is in the navigation) that contains all ministries a user has rights to. This drop down should be contained within it's own form, along with a form containing all controls within the main content section. but because a) System.Web.UI.WebControls.DropDownLists must be contained within a form with runat="server" and B) only one form with runat="server" is allowed on the page; I now have to encapsulate the entire sub navigation and content in a single form. There-by sacrificing good design.

Controls render horrendous HTML

So I've just added a System.Web.UI.WebControls.DataGrid and I've set the DisplayHeader to true and HeaderText to "Name". Ok, let's see here, we have a grid that should be displayed as a table (check). We have a header for that grid/table, so that should be a table header, th tag, (che....oh wait). Where is the th tag? There are too many of these instances to list each one.

System.Web.UI.WebControls.Label renders as a span tag

Did anyone on the asp.net team even look at the HTML specification?

No support for OPTGROUP element

Seriously? I mean, come on, DID ANYONE EVEN LOOK AT THE HTML SPECIFICATION?

Quirksmode is default for new aspx pages

If you truly support web standards how can you default a document to Quirksmode.

No easy way to get HTML from a server-side control

A significant advantage of ajax is not having to render the entire page, especially if sections of the page may or may not be used. On the server an ajax request is not handled any differently than clicking a button or link. There is a significant advantage in being able to request pieces of HTML from the server and respond with that HTML to be rendered on the client (AHAH). but because asp.net controls must a) be apart of a form with runat="server" and b) cannot be rendered before the form is rendered, this is impossible. Besides creating a user control and then loading that control at runtime there is no way to get HTML from an aspx page. Well, no way that I could come up with.

System.Web.UI.WebControls.DropDownList must be contained within a form with runat="server"

Why?

Did I miss something? I'm not too terribly familiar with the machine.config or the web.config, maybe I forgot to include <standards-mode enabled="true" />? Microsoft's marketing machine can preach all they want about standards support (why do I still have to use the Holly Hack in IE7, wasn't this bug fixed? ), but marketing will only go so far. People will tell me that concessions have to be made in order to support the designer and being able to drag and drop a control from the toolbox. But you know what, I don't care, if your dragging and dropping controls from the toolbox then you need to find another profession. Creating web applications is not for you.

Does anyone else struggle with these issues?

Typed Navigation

thardy — Tue, 09 Jan 2007 17:12:00 GMT

One of the features we've worked into our new home-grown architecture is typed navigation. Without typed navigation, urls are strewn throughout the code, and any changes to navigation or querystrings involve updates to many pages. Not only that, providing a page the data it needs to properly initialize can be difficult to manage and very easy to misunderstand by a developer who is working in a page they're not familiar with. These issues cause navigation edits to be error-prone and reduce maintainability and extensibility.

The Need

Consider the following common scenario - You've got a page (let's say EmployeeDetail.aspx) that requires an EmployeeID be passed to it. There are many different ways to get the ID to the page:

QueryString - EmployeeDetail.aspx?empID=100
Session - Session["EmployeeID"] = 100
Database retrieval
etc...

Each method involves different code to set and retrieve the value. In addition, almost every app uses multiple methods in different places and in different scenarios. This results in too many decisions being made by too many different developers, which results in maintenance nightmares. Strict processes can mitigate some of the maintenance pain, if all of your developers ALWAYS use the exact same mechanism, but what about extensibility? What if the page name needs to change at some point? What if you decide to change the way you handle data transfer between pages? Or, more commonly, what if a page simply changes the data it needs or accepts?

Cascading Style Sheets (CSS) is a good example of an architecture with big benefits in UI design - you can make a style change in one place, and that change gets applied in all pages where that style is used. The same measuring stick can be applied to all architectures - can you make a configuration change in a few places (preferably one), and have it applied in all areas of usage? I think most apps would fail this measure in the area of navigation. If a page name changes, most application architectures would require manual changes in many pages - links, code behind redirects, data tables, etc. Even more architectures would fail the test if a change is made to how data is transferred. If a QueryString value changes from empID, to eID, how many code changes would need to be made? What if a page now requires an orgID? Or how about if you move from QueryString to Session, or vice versa? This is where good architectures shine in the long run. Yes you can continue to change the font manually in all your pages when your app is small, but heavy usage of CSS is now widely accepted as best-practice simply because style maintenance and extensibility become absolutely crazy as the number of pages in your site gets large. Why should navigation be any different? It gets just as crazy as your app gets large, and can benefit just as much from a consolidated architecture.

The Solution

Our solution is to use typed navigation. There are several potential architectures available, one of which is PageMethods. There's a great list of the benefits of typed navigation on that page, so I'll try not to rehash all of them here. We took a good look at this solution before developing our own architecture, but decided we wanted much more control over our navigation. Also, the PageMethods solution is locked into generating urls with QueryStrings, and it involves pages calling specific methods in other pages, which our new architecture steers clear of due to MVC principles.

Our architecture includes the following:

Typed Location objects - every navigation destination (View) has its own Location class
Each Location class defines a constant "ViewName" which maps to a url defined in a database, so no urls or page names are ever written in code
Each Location class can have multiple constructors - the constructors provide all the contracts to create the View and allow pages to fulfill multiple roles (list/detail based on what data is sent to them)
Usage in links - a new Location object is created in code-behind and used to set the Location property on one of our HyperLink controls. If set, the HyperLink control has the Location generate its URL when the control is rendered.
Usage in server-side redirects - a controller simply creates a new Location object and calls a public Navigate method on its View
Hydrating Location objects - our base Page class takes care of rehydrating the location object and transferring its data to the View

Here are the only two options a developer will see regarding Navigation in our app:

For a HyperLink:

lnkEmployeeDetail.Location = new EmployeeDetailLocation(employeeID);

For a server-side redirect:

_myView.Navigate(new EmployeeDetailLocation(employeeID));

Since all this is handled by the architecture, changes can be made in just a few places and totally change the Navigation mechanism. We can switch from QueryStrings to Session variables, or rewrite URLs, or change how we rewrite URLs as often as we want. No code that actually uses the Navigation would ever need to change, and page names can change without missing a beat. All the code written to create strongly-typed Location objects would continue to navigate as usual. If a page's initialization requirements changed, then code would break at compile time instead of runtime, with a very clear and self-describing explanation of exactly how the new Location object needs to be constructed. That's a lot better than having some forgotten link deep in your app with an obsolete parameter definition getting discovered by a customer after you've published your app to production.

Typed Navigation is one more step we're taking to make our code easy to work with and understand, regardless of how long it's been since anyone's touched it, how many developers have had their hands in it, or how large it grows.

Persistence via Attributes

thardy — Fri, 20 Oct 2006 13:12:00 GMT

In the new architecture we've been developing, one of the features we've developed is a common persistence mechanism. Once again, our attempts are to make development as clear and painless as possible. We want to make it incredibly easy to write good code, and difficult to make mistakes. As our development team grows and code authors move on to other things and other devs end up maintaining that code, we want it to be downright difficult to misunderstand or misuse anything.

Persistence is one area that we've seen misused in the past. Basically, anyone can put anything in Session or ViewState from almost anywhere they want. Well, they can from the code-behind of pages, which, like I discussed earlier, ends up getting a great deal of logic thrown in there. We decided to put a stop to this in our new architecture.

We've refactored all the persistence code into base classes, and we're using attributes to decorate our View properties like the following:

[Persist(PersistenceType.Session)]
public int IndividualID {get{} set{}}

This allows us to very simply specify what needs to be persisted and how. Currently the three different methods of persistence we're starting with are - ViewState, Session, and Process.

ViewState - this one is pretty self-explanatory

[Persist(PersistenceType.ViewState)]

Session - this is for page-level session only. It persists the data for as long as the user doesn't navigate to a different page. The fact that we've refactored all our persistence code allows us to implement a very aggressive state management strategy that deletes any session data that does not EXPLICITLY belong at any given time.

[Persist(PersistenceType.Session)]

Process - this is for state that needs to be maintained across pages. If a page wants to enlist in a shared-state scenario (like a wizard or any sequence of pages the user can move back and forth between). The developer just passes the name of the process to the attribute's constructor, which assumes a Process persistence. Once again, due to aggressive state management, we immediately delete any process data that isn't explicitly enlisted in by the currently loading page.

[Persist(ProcessList.RegistrationProcess)]

For state that needs to be persisted across the user's entire session, our base Page class will maintain this responsibility. No other code should have this capability. Also note that nothing in our Controllers or business layer can push anything to persistent state. Those layers deal with explicit instructions and methods, some of which may store things in the database, etc, but there's no concept of a Controller saying, "I want this to be placed in persistent state". Controllers just manipulate properties and expect them to be stateful. It's up to the presentation layer to decide how something should be persisted. The difference between WinForms and WebForms is so great that the idea of placing that logic in the Controller makes no sense to us.

As to the performance issues of using Reflection to read and act upon attributes, we feel it's negligable compared to the benefits. We ran some simple tests, and found that using Attribute-based persistence was approximately 100 times slower than not using Attributes. While that may sound huge, it's not when you're talking about the difference (in the worst case) between .00281 and .000228 seconds. Or, in a longer running scenario, between .000268 and .0000363. Not only that, but we've researched several methods to make long-running reflection usage far more performant via the use of Reflection.Emit and also ASP.NET 2.0's Dynamic Methods. Once we've solidified other areas of our new architecture, we can go back and tighten the screws.

These changes will increase the visibility and maintainability of our code by allowing any developer to very quickly see exactly what is persisted and how. Having all our persistence logic refactored into one place will eliminate any potential mistakes a developer could make in persisting data, and will increase our agility in extending the functionality in the future. The point is, there's too much to gain from Reflection not to use it.

Wrestling an Enterprise Architecture out of .NET

thardy — Fri, 22 Sep 2006 23:24:00 GMT

As a growing "Software as a Service" (SaaS) development shop using .NET we've encountered many growing pains and some of the speed bumps inherent in the architecture that many others probably have as well. I'd like to express some of the issues we've encountered and hear if anyone else would like to start a dialog on the shortcomings and potential solutions to scaling enterprise .NET development.

The bigger the code, the bigger the problems

The typical architectures espoused by .NET aren't well-designed for large, "always-on" apps. This has become clear to us as our development group and our codebase have grown. SaaS is a big factor here as well, since best-practice is quickly discovered to be a rather tight, incremental release schedule. As our development group scales, and feature demands increase, the framework everything is written in begins to show its strengths and weaknesses. It's the sort of thing that is difficult to see until many hands have been in the same pot over a period of years. J2EE seems much more geared towards large, enterprise apps, with more emphasis on strict contracts and black boxes. While many of the Java frameworks seem like overkill to most .NET developers, it's because most .NET developers don't work on the same codebase for more than a year or two. It seems like Microsoft has made a calculated move to aim squarely between the enterprise and the PHP-type developer communities. We love .NET tools though, and are looking at some foundational architecture changes to tackle these issues.

Misplaced intelligence

One of the key difficulties introduced with .NET is the Page-Controller Pattern. Despite how nice and elegant the most common n-Tier .NET architecture sounds on paper, practice shows that a great deal of intelligence (WAY TOO MUCH intelligence) inherently ends up in the code-behind of your pages and user controls, and thus, smack in the middle of your presentation layer. This produces a tight coupling between the presentation and business layers and a lot of business logic in the wrong place. The commonly espoused reason for decreasing this coupling is the ability to completely change the UI layer - say, to take your existing business layer that you used with your Web pages and slap WinForms directly on top of it. While this would be wonderful, the more pressing reason is the simple need to refactor code for maintainability and extensibility. Anything in your code behind pages cannot be reused elsewhere. While having nice business methods in your business layer like "FetchOrdersByCustomer", or "UpdateProducts" that deal with nice typed objects and collections may make you feel all warm and fuzzy because you have your n-tier bases covered, your architecture bases really aren't covered at all. Or maybe you have your entities possess the intelligence to manipulate themselves. Either way, the majority of custom development occurs within the consumers of these methods. If the consumers of these methods are in your code behind, you will have real problems as your product grows, your development team grows, and the demands on your product begin to pull it in multiple directions. What you really want is an incredibly stupid presentation layer that only has intelligence about itself. It should only know how to present information from a strictly contracted model it knows nothing about manipulating, how to manage state between "locations" (pages, winforms, pocketPC forms, etc), and how to handle client-side behavior. This is another argument for stupid entities as well (our entities do not know how to manipulate themselves), since our presentation layer can reference our entities without having to worry about exposing all that business logic to the presentation layer. I'm sure I'll get some disagreements on that, but that's the beauty of hearing other people's opinions.

A possible solution

The solution we are developing is moving towards something closer to the Model View Controller pattern. Particularly MVC2, which is the same pattern altered for the web. Microsoft's User Interface Application Block is an MVC block, but MVC does not work on the web. MVC depends on the View being directly updatable from changes to the model, so that combined with the complexity of that application block make it unfeasable for our use. Since the web is stateless, there is no way to directly update your UI from changes to the model. What MVC2 does is simply insert the controller into the process coming from both directions (web to model, and model to web). Microsoft has no packaged solution for anything close to MVC2, which is really disappointing, since you would think they'd want to compete more directly with J2EE and fill this gaping architectural hole. There are some packaged solutions from third parties (even more evidence of a serious development need unmet by Microsoft), such as Maverick.NET http://mavnet.sourceforge.net/, MonoRail http://www.castleproject.org/index.php/MonoRail, and something called NWAF http://sourceforge.net/projects/nwaf, but all of the above take rather radical departures from the .NET way of doing things and are a big jump for .NET developers. Things like the basic page lifecycle and ViewState are radically changed. We wanted something that wasn't quite a big leap for our group, yet still gave the major benefits of MVC2.

There has been a pattern that has recently risen to the top of the .NET pattern circles called Model View Presenter (MVP) that attempts to take a stab at MVC2 and still maintain WebForms and ViewState management. I've recently read a few articles that mention Microsoft's CAB (Component UI Application Block) will have some MVP patterns in it, but we're not holding our breath. It's also targeted at Smart Clients, so I don't know how practical it is for pure web-based apps.

We're building our own home-grown version of an MVP architecture for all development going forward. We are also baking in a few more things that we feel are important, such as:

Typed navigation - urls should never appear in code, and it would be nice if the developer knew the exact state data required in order to navigate to that location/view at compile time
Removing all state-management concerns from the Controller layer - controllers should not care anything about how state is persisted or even have to make the decision that something should be persisted. They should just be able to expect the properties on the View to be available.

As we get further along, I'll post some of the pitfalls and breakthroughs we come across.