Note: This demo is in VB.NET and based on my use of spark on a real project; I can say that this will be the first of a few Spark MVC for VB.NET developers. Spark uses C# in the views; I think its going to be a good way, for me at least, to keep up to speed with both syntax.
It seems that bootstrapping Spark in the global.asa (code in general) is not working for namespaces. I’ll have another post early next week about all my next steps but for now just know you need to add your namespaces to a _global.spark
This demo is the process of getting running with spark and replacing the webforms view engine in a new asp.net mvc project. From soup to nuts as they would say…I guess.
Spark Download:
http://sparkviewengine.codeplex.com/Release/ProjectReleases.aspx?ReleaseId=27109
Spark Master Layout (Master Pages)
http://sparkviewengine.com/documentation/master-layouts
Project Source:
ASP.NET MVC new project with Spark view engine (coming soon)
Related posts:
For some reason Visual Studio 2008 has F2 mapped to the object browser…unlike almost every other Microsoft product including Visual Web Developer.
Tools –> Options
Related posts:
First off; what are we calling “Classic ASP.NET Development using Webforms and the MVP Pattern” today? I’d like to suggest we stick with a discussion of the patterns and the surrounding technology.
Component based development using the MVP pattern…or MVP for short
and
Non-Component based development using the MVC pattern…or MVC for short
And I am aware that there are companies working on MVC components/html helpers…so what else are we going to call it? Then again you might be write…what % of “Webforms” developers are using the MVP pattern? 5%?…hmmm…anyway I am sticking with MVC and MVP until I read something better on stackoverflow.com
Here is the document that I presented to a client when they asked for…well a comparison of “Classic ASP.NET Development using Webforms” and “MVC”
Introduction
In the .NET world the MVC pattern is relatively new but it has been the staple development architecture for Java and Ruby for over a decade. Most of the current the debate between what technology is “better” is argued from a developer’s point of view. While the technical underpinnings of a technology can often translate to the projects success; I feel that both WebForms and MVC are mature enough that most projects will do fine with either.
ASP.NET WebForms
Through the abstraction of HTML, CSS, and JavaScript; ASP.NET WebForms attempts to recreate the experience of developing a desktop application. The entire HTTP protocol is successfully abstracted away and developers are present with a faux statefulness that mimics desktop applications. Development teams are able to use a WYSIWIG style of development.
ASP.NET MVC
Out of the box ASP.NET MVC forces developers to understand HTML, CSS, and JavaScript. There is little to no abstraction which can be a double edged sword. On one hand your development team has access to the raw power of the markup & languages that make up the web. On the other; if your development team is not experienced with HTML, CSS, and JavaScript there might be a learning curve.
Decision Matrix
|
Number
|
Topic
|
ASP WebForms
|
ASP.NET MVC
|
|
1
|
Size, Extensibility, Maintainability
|
Your project is small and your team is not experienced with MVC
|
Your project is large (experience with MVC not required)
|
|
2
|
3rd Party Components
|
Your project requires many specific 3rd party vendor components
|
Your project is not bound to 3rd party vendor components (The UI can still be very rich)
|
|
3
|
Open Source
|
Your project team is not comfortable with open-source libraries
|
Your project team is comfortable with open-source libraries (especially jQuery)
|
|
4
|
Extensibility, Maintainability
|
Your customers requirements will not change during development
|
Your customers requirements may change during development
|
|
5
|
Extensibility, Maintainability
|
Your project will never be "extended" or have a feature "added"
|
Your project maybe be "extended" or have features "added"
|
|
6
|
Testability
|
Unit testing is not required for this project
|
Unit testing is required for this project
|
|
7
|
Extensibility, Maintainability
|
|
Your project is limited in maintenance hours
|
|
8
|
Compliance
|
There is little to no concern with regard to HTML compliance
|
HTML markup compliance (compliance, screen readers, etc)
|
Notes
Related posts:
I did a short demo of automapper for dimecasts.net. Take a look what do you think?
Ha! Dimecasts.net is my phonebook!
Ha!
No related posts.
When installing WebSVN on windows don’t forget to give read & execute permissions to the IIS user (IURS_BLAH) to C:\WINDOWS\system32\cmd.exe
1: C:\WINDOWS\system32\cmd.exe
If you don’t you’ll get errors like:
CreateProcess failed, error code – 5
or
Error running this command: svn –config-dir /tmp –version
No related posts.
I find myself adding child objects within their parents control. For example; if I was going to add a child. I would call the parents controllers addChild action.
/parent/addChild/2
In this case 2 would be the id of the parent that I wanted to add a child to.
Doing it this way I don’t have to keep an internal track of which parent the user wants to add a child to.
For example /child/create does not tell me what parent I am going to associate the child with. In this scenario I would have to put the parent ID in session or something first.
Not sure if what I am doing is “right”….I think so.
No related posts.
I have to admit I am total bias towards MVC but hear me out. I have yet to work in an organization that implements an OOP or even MVP when using WebForms. It’s all been directly bound controls to data readers/sets/tables. No object model, no business object layer, page_load is used and abused, etc. It can’t be stated enough that MVC will not save a project from the bullshit code that is forms over data crap but at least there is hope in the form of a tiny amount of guidance from Microsoft. </rant>
In the .NET world the MVC pattern is relatively new but it has been the staple development architecture for Java and Ruby for over a decade. Most of the current the debate between what technology is “better” is argued from a developer’s point of view. While the technical underpinnings of a technology can often translate to the projects success; I feel that both WebForms and MVC are mature enough that most projects will do fine with either.
The technical debate does nothing for those who are trying to persuade their organization to consider ASP.NET MVC. What I am trying to present here is a list of decision points an organization can use when deciding on MVC vs. WebForms.
Through the abstraction of HTML, CSS, and JavaScript; ASP.NET WebForms attempts to recreate the experience of developing a desktop application. The entire HTTP protocol is successfully abstracted away and developers are present with a faux statefulness that mimics desktop applications. Development teams are able to use a WYSIWIG style of development.
Out of the box ASP.NET MVC forces developers to understand HTML, CSS, and JavaScript. There is little to no abstraction which can be a double edged sword. On one hand your development team has access to the raw power of the markup & languages that make up the web. On the other; if your development team is not experienced with HTML, CSS, and JavaScript there might be a learning curve.
|
ASP WebForms |
ASP.NET MVC |
|
Your project is small and your team is not experienced with MVC |
Your project is large (experience with MVC not required) |
|
Your project requires many specific 3rd party vendor components |
Your project is not bound to 3rd party vendor components (The UI can still be very rich) |
|
Your project team is not comfortable with open-source libraries (expecially jQuery) |
Your project team is comfortable with open-source libraries (especially jQuery) |
|
Your customers requirements, possibly by contract, will not change during development |
Your customers requirements may change during development |
|
Your project will never be "extended" or have a feature "added" |
Your project maybe be "extended" or have features "added" |
|
Your project is mission critical and deserves the comfort provided by unit testing |
|
|
Your project is limited in maintenance hours |
|
|
Your project cares about HTML markup compliance |
I think that most projects will be able to succeed using either technology. The question is simply how much pain will you cause your developers? Will you stick with web forms and create an endless maintenance cycle? We know how much developers love maintenance programming. Or will you force them out of their comfort zone and make them learn something new for the sake of your project?
Related posts: