I am writing an ASP.NET MVC application that combines a set of features from existing applications. The new application is suppose to use UI features and logic created (especially for this purpose) in the existing applications.
For that reason I wanted to create in the existing applications some kind of a "blackbox" that I will be able to drop in my new application along with a matching connection string, and it will work independently, binding data on it's own.
I thought about using partial views, but I am having trouble with passing the model data to it, since the controller of the new application should not know about the model of the existing applications.
I can not use ASP.NET WebForms, since my application should be a "postback-less" application, and ASP.NET AJAX toolkit or frameworks alike are out of the question.
Any help would be greatly appreciated.
Thank you,
Katie
Portable areas might help.
Related
I'd like to use for my next project Ext js and ASP.NET MVC.
I'm wondering what would be the best way of using this two framework together. So far I did some project using ASP.NET MVC, where every action method returned a view and reloaded the page. The Ext js mvc application uses a single page approach.
As I'm pretty new to ext js so I'm wondering if someone could share some experiences of building real world application using this two frameworks.
You can use extjs as you think is better for you. You can use its components as simple widgets or create a full javascript (extjs) client. However, which are the real requirements? a single page client or a traditional client?
In our current project we started using ASP.Net MVC Framework with extjs widgets, it was ok for a while but the customer wanted more and more sophisticated UI and a better user experince (among other thing) then, we changed the app, we left MVC models and controllers (views were removed) and we created a full javascript client with extjs 4.1.
After that we realized we were using an ASP M_C framework (with no views) and that was a nonsense so, we took the ASP MVC project away and replaced it by a WCF Rest service (it also could be done with an ASP.Net Web Api).
We feel proud of our decision and the resulting design. If you can, if you know extjs (learning it is rather hard) and javascript and, if you have support to your decision then, keep your application splitted in two:
a server-side service/api and,
a full javascript application.
Good luck!
I'm not sure I'd agree with the answer by #lontivero, I'm currently working on a project using ASP.NET MVC as the backend and ExtJS as the front.
You do, as pointed out, loose the V from the ASP.NET MVC stack and you end up needing to duplicate you C# view models in you ExtJS Models on the client side but I've found using MVC as a backend (effectively as a rest based collection of Json end points) absolutely fine.
You can utilise the model binding, model validation in MVC whilst leveraging the full client side js app in Ext.
I'm curious as to the points you didn't get on with using this structure (I'm not saying it's perfect, but it does seem to work)
We used Ext.NET (versions 0.x-1.x) in our previous projects. Even after a comprehensive effort to upgrade our projects to the (now current) version, we had to drop Ext.Net 2.x out.
If it fits you, it can help.
The main problems with Ext.Net were (several) incompatibilities with ASP.NET and a lack of trust. They used to keep their schedule, it's far from it for last 2 years or so. And they are behind ExtJS.
I have created a custom MVC Forum application. But I'm starting to think that although it works great as is, I'm going to need to get it to work within other MVC apps (In fact I have actually been asked that already).
What is the best way with an MVC app to structure/develop to make it as easy as possible to integrate into an existing MVC application?
Areas? Develop within a sub folder from the start? Or is it just you have to work through and merge configs/controller clashes if necessary.
No need to Config or ... . you only need to create ability in your Logon Model and it's Controllers. A complete example is in Asp.net MVC 4 which Microsoft has added more libraries for authenticate from other sites/profiles. Also the model has changed a few in properties. see this technology or download MVC 4 framework to learn it. it's easy.
I always used asp.net webforms with the MVP pattern, it works great for what I need, I basically create a project where all my business rules reside, validation etc... and I then implement my views in the webforms project.
Now we're starting to use asp.net MVC and using the MVP patter doesn't make much sense, right? So what could be a good approach to create a scalable and testable project using MVC that won't make me create my data objects and do validation on the controllers. I don' want to have the same code in different places...
If a web user wants to update his/her profile on the site, there would be some validation rules for when a submit button is pushed, like email address cannot be empty, must be valid and must not exist in the database.
These same rules should be applied if I try to update his profile using the internal admin section without having to duplicate the code there...
If you can point me to a good sample project that deals with this would be great!
Thanks in advance!
You should use the MVC pattern with ASP.Net MVC.
The NerdDinner tutorial is a pretty detailed example for MVC, you can also get a book that includes the tutorial (you might want to wait for the version that covers ASP.Net MVC 3). There are plenty of resources on Microsoft's ASP.Net site.
You can always consult Google.
ASP .NET MVC was built with the Model-View-Controller (MVC) pattern in mind. That would be the pattern you'd want to use.
In addition to the resources magnifico provided, I know others have recommended the some other tutorials. I don't know if these have been updated to the latest version of the framework, but they should still serve as decent beginners.
MVC Storefront series
MVC Music Store
Also the Microsoft Patterns & Practices group recently released Project Silk which gets into more advanced techniques involving a lot of AJAX management of the UI. There's interesting stuff there.
I currently have a web application written by ASP.NET MVC. Now I want to add a web service so that some people can easily build application upon it. Shall I just create the asmx in the MVC Web project or create another project referencing to the Model project? And what's the pros and cons?
Thanks in advance!
Easy decision - if your MVC Web project depends on the web service at all, keep it in the MVC Web project. If not, create a separate project for the web service with reference to your model.
Keeping projects seperate allows people to read and understand your code more effectively. If your service makes use of your model, but is not part of that model, than it should definitely be a standalone project with reference to the model. This is clean design.
for my opinion I would do something like this in my solution
solution.Model -- the model that reflects your db,
solution.Repository
solution.MVC -- your model will be the refined Model, referencing the solution.Model
solution.Test
solution.WebService -- referencing solution.Model
I keep my Model outside my MVC Web application and just put the refined ViewModels in my MVC Model folder. I don't know much about pro's and con's but this is just a better way of doing it for me.
Doing this, you can use your Model anyway you want. Maybe you want to use it for WebService as what you ask. Or for another Application. You just reference your Model project to other projects that you need them.
I would look for Odata -> WCF Data Services formaly know as "Astoria".
If you are using for example linq-to-sql or EF you can make your data in a restful manner availale and provide a basic api...
You can define your endpoint like you do in WCF because the underlying service is based on WCF. And I would use a different namespace...
Website
http://msdn.microsoft.com/en-us/data/bb931106.aspx
Beginners guide with videos
http://msdn.microsoft.com/en-us/data/ee720180.aspx
open data format
http://www.odata.org/
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