In order to truly port SpellDamage to the ASP.NET MVC framework, I need to adopt some RESTful conventions. It’s not entirely a simple process to port a web forms ASP.NET site to MVC, especially if the whole MVC pattern is unfamiliar. Some of the things that were handled for me in web forms need to be done more manually in MVC. That’s not necessarily a bad thing, it has forced me to mold SpellDamage into a better application.

First I need to ensure my controllers are doing just that, controlling. You could almost think them as conductors, orchestrating the application. They contain actions, which you imagine are the things that happen on the page such as list, create, edit, etc… Controllers aren’t aware of how to retrieve data, and shouldn’t really contain a whole lot of business logic either. They control the flow and rely on models and views for the other tasks (data/business logic and presentation).

Models need handle the brunt of the work. They perform the data retrieval and business logic. They don’t understand the flow of the application, nor how to present anything to the application user. They rely on controllers and view for that.

Views handle the presentation tasks. They aren’t aware of the flow of the application and have no idea how to retrieve data. They rely on controllers and models for that.

In light of that, I need to make a lot of changes, so I went straight for the notepad and pen. What follows are my plans to change the calculation process in SpellDamage forever. In the process, everything will have it’s place and responsibilities in the application… making future changes a cinch (in case you didn’t see it, check out my preview of next years upcoming features!).

I used a digital camera to make these shots, I didn’t have access to a scanner today. The following picture (click to make it bigger) is the first two steps of the new calculation process:

In the pic above (click to enlarge), you can see the initial UI is responsible for gathering the inputs from the user, creating a UIinputs specification and sending it to the SpellFactory. But, before it can get into the SpellFactory, the SecurityGuard does a quick check to make sure it’s ok (don’t pay attention to misspellings in the pic).

After it clears security (see above pic, again click to enlarge) the SpellFactory reads the UIinputs specifications and “creates” the spells based on the specs. (in SpellDamage, the specs are things such as level, class, talents, buffs, etc…). Once the spells have been created, the SpellFactory passes the spells over to the Calculator.

The Calculator takes the spells and performs the calculations, creating a results package (see above pic) which is then delivered to the UI. The UI then opens the package and displays it to the application user. It’s important to note that, at this point, the UI can be anything. It can show the results package in many formats, such as HTML, XML, JSON, etc…

So that’s a quick overview of the upcoming changes behind the scenes of SpellDamage. I hope it was informative, and you can get a better idea of what’s going on.