While making a website in MVC3 on ASP.NET, I got the error: “The entry ‘xyz’ has already been added.”.
I realized that somehow my data Context was already being created by EF and I was getting this error.

The fix for this was to change my ConnectionString (in web.config) to not be of this same name.

I realized that in code-first models, the connection string had to match the database being created, which should match the context class, derived from DbContext.  This was happening in this “database-first” case as well.

I made this short post because many folks are baffled by this error, and I hope this post helps them.

There are already many posts on this topic and they mainly focus on why MVC is better.
I thought it might be helpful to explore the cons of using asp.net MVC and would like your input on this.

Let’s start with an overview…
As you may know, MVC is built on the Model-View-Controller pattern which has been adapted as a Model-View-Presenter pattern; the latter isolates the Presentation layer from the domain knowledge.
The Potel paper which defines MVP is here: http://www.wildcrest.com/Potel/Portfolio/mvp.pdf and Fowler has a good article here: http://www.martinfowler.com/eaaDev/uiArchs.html

Regular asp.net
The regular aspx model is based on a simple 1-1 request-resource relationship.
In essence, a URL maps to a file on disk. So, a URL request goes to the (IIS) web server which has a .aspx mapping which routes the request to .NET which calls the target page.
The page class inherits from System.Web.UI.Page which implements the IHttpHandler interface that defines the  “ProcessRequest()” method, which is the method called to get the output to send to the browser.

asp.net MVC
In the asp.net MVC framework, a controller handles an incoming request, so there is notion of an aspx page to service the request. A (single) Route Table, currently set up in the global.asax file, specifies which controller a request should go to. The routing mechanism is part of the .NET framework, outside the MVC dll. So, although MvcRouteHandler is the default one used, you can define your own controller. The RenderView() call on the controller is delegated to the ViewEngine; the default being WebFormViewEngine but you could use a third party’s.
The RenderView() is called on the ViewPage, which derives from System.Web.UI.Page. In turn, this calls the method (you guessed it) ProcessRequest, just like regular aspx.

Differences, Pros and Cons
So, what is the best model to create a web-site? It depends!!!
No, seriously, as with many architectural decisions, the choice is not about which technology is better but more about what is practical.

Here are some key differences to consider:
MVC provides indirection and abstraction between a URL and the processing rather than a URL mapping to an aspx page.
Most businesses prefer clean URLs; something like product/nivea/lotion is better than than product.aspx?brand=nivea&category=lotion. No more URL Rewriters.

MVC also abstracts the URLs from technology/implementation and you can switch out your back end without affecting the URL. Otherwise, you have to use ISAPIs or something to map your old URLs to the new implementation (a comon problem).
From a design standpoint, a view can cleanly service multiple URLs; with regular aspx, you had to add querystring parameters and switching logic to service multiple URLs from a single page.

MVC lends itself to some good object modeling and software design but the project needs to have someone who is skilled in that respect.
The regular model is easier to understand and I would recommend it for simple websites which have a known amount of URLs that are functionally independent. So, a company website is a good candidate.
A website with heavily data driven URLs would be better handled with MVC. A product catalog is a classic poster-child for MVC; a website with custom URLs for each user or a website serving images or other resources based on URLs would be good candidates; sites with co-branding (similar page structures and data) might be better serviced by MVC, where a URL pattern exists across brands, e.g. nivea/products/lotion and dove/products/lotion.

The MVC model provides extensibility at multiple levels; you can use your own controllers and view engines. In reality, you are most probably going to use the default engines but then there is no extra cost for this flexibility.

From a software design/architecture perspective, MVC lends itself to a clean and robust design and flexibility.
So, when would regular asp.net be a better choice?

The answer depends on:
– Requirements/characteristics of the website:
I think, if you have a website with URLs with fairly independent content, it might be faster and easier to use regular asp.net.

– Legacy codebase
If there is a legacy codebase and a running regular asp.net website, you better have a good reason for switching to MVC just to add features. This also involves an operational overhead for deploying the newer technology.
Also, if the current design needs to be reworked just to make it MVC, it may not be worth it.

– Business
If your company is a consulting shop that has to quickly deliver websites and you employ or outsource to consultants, MVC would add overhead to your delivery schedules and also hamper maintainability because the developers need to know what they are doing if you need to add controllers and views in the future.

– Rresources/workforce
An experienced developer will find MVC intuitive and easier to develop but a developer who has mainly worked in building websites and does not have software engineering skills might find MVC daunting and confusing especially after using regular asp.net for a while.

I am curious to hear your comments on this…

I have been dabbling in the MVC framework and came across this error which threw me in a loop:
The controller for path ‘/foo/bar’ could not be found or it does not implement the IController interface.
Parameter name: controllerType

I finally realized that the Controller class name needs to be the controller name specified in the route dictionary with a suffix of “Controller”.
So, a route handler with controller = “foo”, action = “bar” maps to a method named “bar” in a controller class named “fooController”.

Silly oversight on my behalf because I was naming my class the same as the name of the controller. I wonder why the MVC team added a suffix.

As part of figuring this out, I came across a routing debugger tool:
http://haacked.com/archive/2008/03/13/url-routing-debugger.aspx