I have an application that will support multiple sites. The site will be determined based on the url.
For example
http://myapp/site/abc123/...
and
http://myapp/site/xyz123/...
The site code will drive a lot of the functionality for example themes, available modules, etc...
Questions:
1-)I need to validate the site code is valid and if it isn't, it should direct the user to an info page. I was looking at using IRouteConstraint, is this appropriate? Are there other/better options?
2-)Any gotchas with this approach (using url to identify site)? Is there are better approach?
Solution
I ended up creating a Custom ActionFilter and check the sitecode in the OnActionExecuting event. That seems to work well and fit better than the IRouteConstraint.
The system I have implemented uses Urls to identify unique page content within a single site and the routing process is pretty straightforward. That being said, you may want to consider making use of Areas in your MVC application. With Areas you can have multiple sections to your website that all have their own MVC structure which can run semi-independently.
Essentially, you will have one base routing definition that lays out some defaults and then the rest of the "sites" will define their own routes pointing to controllers and views in a separate location. It's pretty easy to set up, you'll just need to make sure you're using version 2.0 of ASP.NET MVC. Here's a decent looking tutorial on ASP.NET MVC Areas and Routes. In the current model which MVC 2.0 supports you'll have a single Web project for each area, but that is not necessarily a requirement. Phil Haacked has some code for ASP.NET MVC Single Project Areas if you're looking for another example of the technique, although you, personally, will probably benefit more from the first article.
So long as you define good routes that have clear and measurable constraints, you shouldn't have too much trouble laying out the website you've described.
I ended up creating a Custom ActionFilter and check the sitecode in the OnActionExecuting event. That seems to work well and fit better than the IRouteConstraint.
Related
I'm newbie in angular so i have two questions on AngularJS routing. Deeply sorry if this has been answered. tried a brief search, didnt find exact match.
I get the idea of SPA, the cost of asp.net server round trip,
however, what's a valid real world scenario that make best use of
both server side routing and client side routing together? or simply
give up the asp.net mvc routing at all?
If partial routing rules
defined on both side, isn't it a bit messy?
well, that depends on what you need I saw some people doing a mix of routes between angular and MVC, you can take a look to he boilerplate and hot towel projects for asp.net and angular combo take them as reference, both are like starter kits.
In my personal opinion (and this is subjective), I prefer to use a RESTFul architecture / SPA let angular do the routing and have web API or service stack as a middleware very much like the mean.js approach for me it's a cleaner and more natural for a SPA application.
take a look to this article that talks about rest API and some best practices.
I don't know if there's a perfect answer since it all depends on the project you're working on and the preferences of the dev team. I personally like keeping some of the MVC concepts (mvc views, routing, etc.) and just using angular for a given page's functionality. I don't make use of the angular routing at all. Obviously it would be a different story if you were trying to create a full SPA.
But I find that in a lot of cases (especially if working on an existing app written in MVC) you can introduce bets and pieces of angular without taking it all the way. If you're trying to get rid of page redirects entirely and want a full SPA experience then you should probably use a service approach instead as already suggested (if you want to stay with the Microsoft stack, Web API is a good option).
Django has the Flatpages app, which lets site admins change content on specific pages without changing code. Flatpage content i stored in the database, sort of like in a CMS. Flatpages are typically used for about-pages and such.
Are there any good equivalents for ASP.Net MVC? I.e., a convenient way to manage page-content persisted to a database.
No.
Django seems closer to a CMS then "ASP.NET MVC" which is both a framework and just a general design pattern.
Have a look at http://http://cmsmvc.codeplex.com, it allows you to create pages, and manage content on the page.
The solution is still in early stages, but it could help you out.
Ive been doing a bit of research / reading into mvc recently and was just wondering what the main purpose is.
is it as some people say to seperate the logic from the html
or to create clean url's
i could be missing the point completely, but asp.net forms really seperates the logic from the html and if you just want clean url's why not use a mod_rewrite rule?
MVC is a software engineering concept which is used more widely than just in ASP.net.
In a nutshell it encourages strong separation of:
business logic (the Model) the code which does all the brute force work behind the scenes; dealing with the database, performing large calculations; and
user interface logic (the View) the code which presents information to your users in a pretty way.
The C is for Controller - the ligaments that bind the bones of the model and the muscles of the views and allow them to communicate with each other cleanly.
You are correct that 'normal' ASP.net uses code-behind files so that page markup is kept separate from the code that generates that markup (in contrast to languages like PHP where code is embedded directly amongst HTML), but MVC ASP.net encourages even more separation in the ways I described above.
Take a look at this tutorial for a more detailed discussion of the pattern. Also take a look at this SO question
The MVC pattern has nothing to do with rewriting URLs. ASP.net MVC might make this easier but that is not by any means it's main purpose.
Testability is a big benefit of using ASP.NET MVC. It is non-trivial to write unit tests for ASP.NET winforms. It is much easier to unit tests for Controllers.
If you are doing MVC correctly, your views should be very light, and a lot of your logic is implemented in the Controllers.
Let me compare the two for you:
Asp.net web forms
They matured the old ASP technology that was much more like PHP. Code and presentation were piled up in the same file. Asp.net web forms upgraded this model by providing a mechanism of separating the two. But they built on top of the good things that windows application developers had. The drag drop interface creation with control events just like they exist in a windows application. Event thought code was separate from HTML, they were not separated. You still reference a lot of view controls in your codebehind, hence they're still very much bound to eachother.
Therefore it was rather easy to start developing on Asp.net web forms. But non savvy developers soon got to a bottleneck they didn't know existed (like slow postbacks due to huge view state etc.). Technology used some tricks to make this work. But on a serious large scale application this became quite a problem. Developers had to mingle their code to make it work with Asp.net web forms framework. Their complex forms had complex codebehinds with hard maintainable code with complex state.
The good (as well the bad) thing were at that time rich server controls. Nowadays with web 2.0 they don't seem rich anymore since they don't actually support client side functionality as much as they should. So Microsoft decided to also cram in something else. Update panels. That made partial rendering (and Ajax) possible with almost a flick of a finger. But it came with a cost. Everyone that used (uses) it soon realised it's not a viable solution that a professional application could implement.
Asp.net MVC
Now we have a new technology that doesn't have much in common with Asp.net web forms except for its first part of the name. MVC framework actually does separate code from user interface (view). Controller actions (code that executes on any HTTP request) is kept small and doesn't do anything with visualisation (it doesn't bind data to certain controls etc.). Controller action barely prepares data for the view to either consume or not. It's up to the view. Controller code doesn't in any way shape or form reference any view controls or anything. They're actually separate in MVC.
Views on the other hand just display and provide data. They can be partially or fully rendered. They support Ajax functionality to the point that everyone would like to use. Actually everything is separated into basic little things. Divide et impera (divide and conquer) seems to be the save-line here.
There's not hidden functionality. No flirting with windows development. It pure request response framework. Developer has the ability to 100% control the visual aspect of their app. But for the cost of not having rich controls out of the box. Those may be provided by the community or some developers prefer to create per purpose controls that serve the process much better.
Which one is better then?
Both have their pros and cons. But if you decide to build a semi complex, modern and maintainable application I'd suggest you give MVC a go.
But if all you need to do is a 15 screens application (without any particular interface requirements) it would be much faster to create it using Asp.net web forms.
MVC is a design pattern. Its purpose is to separate business logic and presentation details.
ASP.Net MVC is a mechanism to create web applications using ASP.Net and the MVC pattern.
One of the features of ASP.NET MVC is the ability to use SEO friendly URLs to provide commands to the controller part.
You can do as you have stated but ASP.Net have provided you a mechanism to do this easier.
The way ASP.Net Webforms was designed is that it made it easy for you drag controls on to the web form and code the logic underneath. ASP.Net MVC is designed so you separate your concerns easier.
The URL part of the ASP.NET MVC framework is just a modern phenomena to produce search engine friendly urls. They've infact been around long before the Microsoft team decided to add them to the framework (which required IIS7 before it could be done with no IIS extension).
The greatest pros in my view come from being able to test more easily, and separating off the parts of your application more cleanly. The whole ActionResult architecture of the ASP.NET MVC framework makes it very easy to switch from AJAX to plain out POSTs.
Delphi 5 use to employ the MVC model for its ISAPI extensions, 10 years ago.
MVC is not just an ASP.net thing, it is a design pattern that was widely accepted before it was created within the .NET framework, the thing about MVC is the separation of data from presentation(user interaction) from the business layer. It was just a way for Microsoft to offer that type of design pattern under the .NET framework
Although guys before me already give enough answers to the queston of purpose of ASP.NET MVC there is one thing I would like to add.
The ASP.NET Web Forms tried to abstract html and web from web development. That approach lead to the lacks in performances and usage of rich javascript frameworks.It was possible to create web application without actual knowledge of the web.
And to answer to you initial question, the purpose of ASP.NET MVC, I'll quote Dino Esposito:
With ASP.NET MVC, you rediscover the good old taste of the Web—stateless behavior, full control over every single bit of HTML, total script and CSS freedom.
MVC existed long before people tried to use it in HTML pages. The main reason for MVC is to get a grip on the logic to drive your application. MVC allows you to clearly separate things that should be separate: The model, code which converts the model value for the display and the code which controls the model.
So this is not related to HTML or URLs in any way. It's just that MVC makes it really simple to have clean HTML and simple URLs.
I need your advice regarding migration. I want to migrate existing project to ASP.NET MVC and I can figure out the proccess except of url rewriting issue:
for example how can I make following route:
http://www.eireads.com/ireland/mayo/cars-3/1263-used-cars-citroen-c5-for-sale.aspx
Or maybe I could somehow keep supporting legacy routes.
I think that migrating a web forms applicaiton to MVC is going to be very hard unless you have a clear seperation of concerns in your current applicaiton. If you have followed a design pattern like MVP then it might be easier, but if not then much of your business logic is likey going to have to be moved to controller classes and much of it re-written.
I would start by extracting your model, this should be fairly easy, then identifying your controllers and actions and seeing how much code you can re-use. At this point you should be able to discern whether or not you can migrate or if you'll be better off re-writing portions of your applicaiton.
Default URL patterns in ASP.NET MVC are http(s)://(appdomain)/(controller)/(action)/(par/ame/ters)
So your url above should fit into that pattern. You can change the pattern to account for other things (like namespace for example). Your URL pattern might be:
http://www.eireads.com/cars/used/ireland/mayo/citreon
where ireland, mayo and citreon are the in put parameters.
I think you should really re-write your question and try to detail exactly what you are attempting to accomplish here.
If you are asking how to migrate an existing WebForm project into ASP.NET MVC keeping the same URL rewrite, the answer is; not easily. The models are too different.
Yet, you mention "routes" in the end, which make me think you are speaking like those of the System.Web.Routing namespace. So are you dealing with an existing MVC app and want it too look like that URL path? I can't tell. I am confused.
When I first heard about StackOverflow, and heard that it was being built in ASP.Net MVC, I was a little confused. I thought ASP.Net was always an example of an MVC architecture. You have the .aspx page that provides the view, the .aspx.vb page that provides the controller, and you can create another class to be the model. The process for using MVC in ASP.Net is described in this Microsoft article.
So my question is. What Does ASP.Net MVC provide that you wouldn't be able to do with regular ASP.Net (even as far back as ASP.Net 1.1)? It is just fancy URLs? Is it just for bragging rights for MS to be able to compare themselves with new technologies like Ruby On Rails, and say, "We can do that too"? Is there something more that ASP.Net MVC actually provides, rather than a couple extra templates in the File->New menu?
I'm probably sounding really skeptical and negative right now, so I'll just stop. But I really want to know what ASP.Net MVC actually provides. Also, if anybody can tell me why it's Model-View-Controller and not in order of the layers of View-Controller-Model or Model-Control-View depending on whether you are going top to bottom, or vice versa, I'd really appreciate that too.
EDIT
Also, it's probably worth pointing out that I've never really cared for the web forms (AKA server controls) model either. I've only used it minimally, and never on the job.
.aspx doesn't fulfill the MVC pattern because the aspx page (the 'view') is called before the code behind (the 'controller').
This means that the controller has a 'hard dependency' on the view, which is very much against MVC principles.
One of the core benefits of MVC is that it allows you to test your controller (which contains a lot of logic) without instantiating a real view. You simply can't do this in the .aspx world.
Testing the controller all by itself is much faster than having to instantiate an entire asp.net pipeline (application, request, response, view state, session state etc).
Scott Guthrie explained it in this post "ASP.NET MVC Framework"
It enables clean separation of concerns, testability, and TDD by
default. All core contracts within
the MVC framework are interface based
and easily mockable (it includes
interface based
IHttpRequest/IHttpResponse
intrinsics). You can unit test the
application without having to run the
Controllers within an ASP.NET process
(making unit testing fast). You can
use any unit testing framework you
want to-do this testing (including
NUnit, MBUnit, MS Test, etc).
It is highly extensible and pluggable. Everything in the MVC
framework is designed so that it can
be easily replaced/customized (for
example: you can optionally plug-in
your own view engine, routing policy,
parameter serialization, etc). It
also supports using existing
dependency injection and IOC container
models (Windsor, Spring.Net,
NHibernate, etc).
It includes a very powerful URL mapping component that enables you to
build applications with clean URLs.
URLs do not need to have extensions
within them, and are designed to
easily support SEO and REST-friendly
naming patterns. For example, I could
easily map the /products/edit/4 URL to
the "Edit" action of the
ProductsController class in my project
above, or map the
/Blogs/scottgu/10-10-2007/SomeTopic/
URL to a "DisplayPost" action of a
BlogEngineController class.
The MVC framework supports using the existing ASP.NET .ASPX, .ASCX, and
.Master markup files as "view
templates" (meaning you can easily use
existing ASP.NET features like nested
master pages, <%= %> snippets,
declarative server controls,
templates, data-binding, localization,
etc). It does not, however, use the
existing post-back model for
interactions back to the server.
Instead, you'll route all end-user
interactions to a Controller class
instead - which helps ensure clean
separation of concerns and testability
(it also means no viewstate or page
lifecycle with MVC based views).
The ASP.NET MVC framework fully supports existing ASP.NET features
like forms/windows authentication, URL
authorization, membership/roles,
output and data caching,
session/profile state management,
health monitoring, configuration
system, the provider architecture,
etc.
Primarily, it makes it very easy to create testable websites with well defined separations of responsibility. Its also much easier to create valid XHTML UIs using the new MVC framework.
I've used the 2nd CTP (I think they're on five now) to start work on a website and, having created a few web applications before, I have to say its hundreds of times better than using the server control model.
Server controls are fine when you don't know what you're doing. As you start to learn about how web applications should function, you start fighting them. Eventually, you have to write your own to get past the shortcomings of current controls. Its at this point where the MVC starts to shine. And that's not even considering the testability of your website...
No more auto-generated html IDs!!! Anyone doing any sort of javascript appreciates this fact.
ASP.Net with it's code behind is almost MVC - but not - the one big thing that makes it not is that the codebehinds are tied directly to the aspx's - which is a big component of MVC. If you are thinking of the codebehinds as the controller - the should be completely decoupled from the view. The new .NET MVC rounds this out - and brings a complete MVC framework. Though there are existing ones for .NET already (see Spring.NET).
I looked through a couple simple examples such as this one. I can kind of see the difference. However, I don't really see how MVC uncouples the view from the controller. The view still references stuff that's in the controller. I do see how it makes it much easier to test, and that at least in MVC the controller doesn't have any knowledge of the view. And you wouldn't have to process the view to call methods in the controller. I can see that's quite a leap, even though at first glance it may not seem like much.
I do agree with #Will about fighting server controls. I've never worked in a situation where they were actually used, but many people I know who have, have run into quite a few limitations with them.
Article about ASP.net MVC Vs ASP.net Web form
http://weblogs.asp.net/shijuvarghese/archive/2008/07/09/asp-net-mvc-vs-asp-net-web-form.aspx