ASP.NET MVC vs. Custom MVC Framework, running on ASP.NET

[FarligOpptreden]

So, the past couple of weeks I've been investigating ASP.NET MVC for a very large-scale enterprise web application. I'm all for the idea and methodology, but I've found it quite cumbersome to implement very large-scale, dynamic applications using ASP.NET MVC.

So, just to be different, I decided to implement my own MVC-type framework, based on good old ASP.NET. The version in question is 3.5, but you could very easily implement the same in 2.0. The idea revolves around the following:

1. Break up you application into 3 very distinct projects called Model, View and Controller.
2. Let your Model project contain all your entity classes, representing your Data Model from your chosen database platform.
3. Let your Controller project serialize each entity in the Model project to XML to be transformed with XSLT. Your event handling will also happen in this project. You can access any input submitted by the user by using Request.Form["inputFieldName"]. These would typically be mapped to the properties of the classes exposed in the Model project.
4. Your View project would consist of a single page, for argument's sake called "handler.aspx", that would parse an incoming URL and use parameters specified in the query string to call the corresponding object in the Controller project, which would transform the Model's serialized XML to HTML using a specified XSLT file. This resulting HTML would then be sent back through the response stream in the Controller object.
5. By specifying an action in your URL, the controller would know what to do with the posted data, like updating the model in the database if a "save" action was passed through the URL.
6. You can implement URL rewriting / rerouting through many of the freely available assemblies to achieve nice, friendly URLs, like rerouting http://server/app/entity-type/entity-id/action to http://server/app/handler.aspx?controller=entity-id&type=entity-type&do=action.

That's the basic idea I've been busy implementing, with a basic, working prototype that I managed to build yesterday. This way, I have a lot more freedom in implementing exactly what I want in exactly the way I want, without being limited to web forms in normal ASP.NET, or following the structured route ASP.NET MVC prescribes. Also, using XSLT for View transformations gives me absolute control over the resulting HTML sent back to the client and, if you know your XSLT well enough, you could implement quasi-object-oriented XSLT transformations, including bits and pieces of smaller XSLT files for commonly used entities in your application.

The benefit I found so far for this approach is being able to store different "views" for the same entity in your database and being able to implement new entity views on the fly, without any alteration to the application's code or without the need to recompile and deploy. Sure, you could get the same going using normal ASP.NET MVC, but I just found this XSLT "templating" a lot easier to implement and foresee easier maintenance in the future as well...

Feel free to discuss...

 

[murraybiscuit]

kudos.
the xslt templating method sounds very interesting.
would you need a cms in the mix?
how does your routing handle permalinks?

 

[FarligOpptreden]

kudos.

Thanks.

the xslt templating method sounds very interesting.

Well, seeing as I'm a bit of an XML / XSLT freak, it just made more sense to me than using inherited pages or user controls that are available in ASP.NET. Plus, using pages or user controls doesn't clearly separate your VIEW from your CONTROLLER, as the .ascx / .aspx + code-behind file already act as a sort of "Controlling-View" hybrid. I would like to achieve clear separation of concerns, which I believe XSLT would give me.

would you need a cms in the mix?

I would probably, yes. The prototype I'm working on already contains CMS elements, allowing me to define entities, fields, groupings and sub-entities (to the n-th level).

how does your routing handle permalinks?

Well, since I built my own handler for routing URLs, I can modify it any way I want. I can probably index the permalinks with corresponding REGEX to actual URLs in the database, but I'll cross that bridge when I get there. For now I'm building the custom MVC framework first.

Oh, and jQuery is of course used to handle client scripting...

Another interesting point that I've been prototyping so far is dynamic business rules. Having a completely dynamic engine that allows for almost any conceivable business rule would be a pretty daunting task, right? IMHO, wrong. The idea is to have a custom "Rule" scripting language that allows the user to define business rules and specify whether they should be executed on the client, server, or both... The parsing engine would then generate the corresponding Javascript for the client or C# for the server-side. Injecting and executing Javascript on the client is, of course, fairly straight forward, but executing such dynamic rules on the server would then require late binding utilizing code reflection.

 

[FarligOpptreden]

I actually think copyright should date the first time it was copyrighted, but I might be wrong... The MVC Framework I was toying with WAS MVC 2... WWF is more for Workflow, not specific do web development frameworks.

 

[FarligOpptreden]

I was talking more about the dynamic business rule aspect of your system.

I've tried looking at WWF, but it still seems like a lot of work to achieve complex rules. Might just be that I didn't research it enough though...

 

[semaphore]

MVC in ASP.NET i would rather eat rusty nails.

 

[FarligOpptreden]

MVC in ASP.NET i would rather eat rusty nails.

Can I pass you the ketchup then?

 

[midrange]

Sounds impressive, but

he benefit I found so far for this approach is being able to store different "views" for the same entity in your database and being able to implement new entity views on the fly, without any alteration to the application's code or without the need to recompile and deploy

is there not a workload (time) overhead there, in terms of running through the "DOM" with XSLT in the the view?

 

[FarligOpptreden]

Sounds impressive, but



is there not a workload (time) overhead there, in terms of running through the "DOM" with XSLT in the the view?

There shouldn't be if you keep the markup relatively simple. I've worked with some complex XSLT transformations, building hierarchies of "controls" based on deeply nested XML data. The transformations happen instantaneously, for the most part. Writing "good code" is again the order of the day - if your XML markup is properly structured and transformed with simple, efficient XSLT templates you should receive instant results.

 

[midrange]

Fair enough.

Before the PHP MVC frameworks became popular there was some bloke out in the wilds of the internet who had created a similar framework to yours (in PHP). I can't remember his name.

 

[FarligOpptreden]

Well, I'm making some more progress... I'm beginning to see the limits of Microsoft's XSLT 1.0 implementation in .NET, so here's wishing that they decide to implement an XSLT 2.0 parser in the future.

 

[semaphore]

Well, I'm making some more progress... I'm beginning to see the limits of Microsoft's XSLT 1.0 implementation in .NET, so here's wishing that they decide to implement an XSLT 2.0 parser in the future.

http://blogs.msdn.com/dareobasanjo/archive/2004/05/13/131166.aspx

 

[FarligOpptreden]

http://blogs.msdn.com/dareobasanjo/archive/2004/05/13/131166.aspx

Yeah, I've read that post before... Still, I'm crossing fingers and hoping they decide to change their mind sometime, because XQuery and XSLT 2.0 are not for the same use.

 

[semaphore]

That article is a bit old, it's a pity there hasn't been anything new on this topic. I could find anything relevant to .NET 4.0.

I suppose you have to look at what they're trying to achieve with each Framework revision. To me 3 was all about Linq, 4 is all about parallel.

There are some open source projects that claim to support XSLT 2.0 under .NET...

I personally dont use xslt and will try never too.

 

[FarligOpptreden]

Why, pray tell, would you never try to use it? Is the templating idea a bit too much to get to grips with?

Seriously - XSLT is awesome. It really makes it possible to reuse your Model and Controller (in an MVC implementation, of course), because your Model will just be serialized to XML and be transformed with XSLT. The resulting output can be anything you need - HTML, XAML (for WPF - done it before and its VERY powerful), SVG, CSV, clear text... I think its one of the closest forms of abstraction you can get, from a UI perspective.

 

[Raithlin]

Back in the days when 2.0 was all the rage, one of our developers created just such a system (basically what SharePoint is today), and used XSLT to great effect. This is a good concept, and I'd love to see the final result - but of course copyright applies.

Question: Are you implementing MVC or MVP?

 

[FarligOpptreden]

Back in the days when 2.0 was all the rage, one of our developers created just such a system (basically what SharePoint is today), and used XSLT to great effect. This is a good concept, and I'd love to see the final result - but of course copyright applies.

Question: Are you implementing MVC or MVP?

My idea is basically an MVC-type framework:

• Model to, well, model the entities I'm dealing with.
• Controller to handle all "behaviour" associated with the model and to act as a bridge to the View.
• View to just render the appropriate presentation back to the client, which can typically be any markup language.

The way a request currently works is something like follows:

• Client sends request for a URL to the server.
• A custom HTTP Module receives the URL, does a match to some URL templates stored as REGEX and maps it to the physical URL, stripping out any possible parameters. A URL looking something like http://server/application/view/entity/1/person/99/ might map to http://server/application/handler.aspx?type=1&object=99&action=view. Those REGEX templates are, of course, highly customizable.
• A single page, called handler.aspx, queries the page parameters and calls a factory method to construct the appropriate Controller object.
• The Controller object loads the necessary Model, serializes it to XML and transforms it with a specified XSLT.
• The resulting markup gets pushed into the Response stream and the response ends.

 

[Raithlin]

I know what MVC is - just making sure you do. It sounds like you're on to a good thing. Best of luck to ya.

I trust you are keeping the base code separate so you can easily re-use it...

 

[FarligOpptreden]

I know what MVC is - just making sure you do.

C'mon, you can give me more credit than that...

It sounds like you're on to a good thing. Best of luck to ya.

Thanks.

I trust you are keeping the base code separate so you can easily re-use it...

Of course I am! I'm even reusing the URL rewriting module I built beginning of last year. It works like a dream... I've implemented it in 4 different projects, without any modification, so far.