I'm thinking about going into the ASP.NET MVC scene.
I've seen the videos at http://asp.net/learn, but they havn't impressed me.
So can you answer me, what makes MVC "so impressive", and why does it make life better and easier?
ASP.NET MVC is much more in tune with the technology on which it is layered. ASP.NET Forms attempted to pretend that there was a nice fat stateful infrastucture as there is in a standard WinForms app. However HTTP and Web servers do not like fat stateful applications.
ASP.NET MVC allows for a separation of concerns. The request is processed by a controller not a "Web Page", it chooses how to respond and what UI is needed to present that response. The controller builds the set of structured data needed by its choice of view then hands over that data to the view.
This division allows much easier testing, the view is merely a means to present what should be a complete well munged chunk of data. Its way easier to build a test for something which takes structured data in and responds with structured data.
ASP.NET Forms is almost impossible to test in this way (especially without expensive tools claiming to achieve it). Hence an MVC application is easier to get right and much easier to ensure it stays right by consistently running existing tests.
Caveat: The major draw back of ASP.NET MVC right now is lack of solid documentation. I've been assured that docs are coming "soon".
Have you ever worked on a large project that had great intentions when it started but 3 years later was a complete mess?
MVC is a just pattern it can be misused the same as ASP.NET is misused. It is just harder to do.
Model–View–Controller (MVC) is an
architectural pattern used in software
engineering. Successful use of the
pattern isolates business logic from
user interface considerations,
resulting in an application where it
is easier to modify either the visual
appearance of the application or the
underlying business rules without
affecting the other.
It allows you to separate your logic in a way that makes sense to most people. While at the same time it lends itself well to testing.
Related
I've been developing in ASP.NET for 1,5 years. (I used first Web Forms for a year and when I get a new project I decided to learn MVC) Now I am about changing job where they want me to develop in J2EE or SpringMVC. How long does it take to get practice in those (not to get pro just to reach a level to make good quality software)? I think that those web frameworks are very similar to the web frameworks of .NET I used.
Am I think right? Is there somebody who have changed from .NET to Java (or vice versa)?
I think of it as there are two main things you need to understand in order to build good quality software:
The general principles of the area you're working in
The specific details of the technology you're using at the time.
In the web-space, the principles of ASP.net and the concept of MVC is pretty similar to the concept of the SpringMVC. There are loads of Model-View-* type frameworks, which basically have the same concepts behind them.
You'll have the same set of concerns building an application in Java as you did in ASP.NET - Separate business logic from presentation, connect to a database, appropriate level of logging, security, error management, authentication, etc. etc.
The concepts you learned using ASP.NET you'll be able to re-use in the Java space.
The specifics of how you utilise them will be different (although often, surprisingly similar - compare nunit with junit, Hibernate with nHibernate). It'll take a little while to get to grips with how SpringMVC works and how it's configured, with how to build and deploy a Java project, with the particular structure of the libraries.
But in the end it's the same principles.
Also, particularly in the web space, all of the HTML, CSS, javascript, browser compatibility, user experience is identical. How you include that stuff in your project varies a little, but the actual markup that gets sent to the browser, and the challenges in making it right are exactly the same.
Doing something new like this will help too, because you'll see where the similarities are, and where the differences are. It might help highlight why they're similar.
It would be really good if you got on a project with some experienced Java people on it. They'll have the basics down and be able to structure it so that most of the big risks are managed, so you can get to grips with the technologies and differences to start off with.
Most really good developers can develop in several languages. I recommend you add Java to your list.
My company has a fairly old fat client application written in Delphi. We are very interested in replacing it with a shiny new web application. This will make maintenance a breeze and many clients want a web application.
The application is extremely rich in domain knowledge, some of which is out of our control. Our clients use the program to manage their own clients and report them to the government. So an inaccurate program is a pretty big thing. The old program has no tests. We are not sure yet if we will implement automated testing with the new one.
We first planned to basically start from scratch. But we are short handed and wanting to basically get everyone on the web as soon as possible. So instead of starting from scratch we've decided to try to make use of the legacy fat-client database.
The database is SQL Server and can be used in SQL Server 2008 easily. It is very rich in stored procedures, functions, a few triggers, and lots of tables with over 80 columns... But it is decently normalized. We want for both the web application and fat client to be capable of using the same database. This is so that if something breaks badly in the web application, our clients can still use the fat client and connect to our servers. After the web application is considered "stable", we'd deprecate the fat client.
Has anyone else done this? What tips can you give? We want to, after getting everyone on the website, to slowly change the database structure to take care of some design deficiencies. What is the best way to keep this in a data access layer so that later changes are easy?
And what about actually making the screens? Is there any way easier than just rewriting an 80 field form in ASP.Net? Are there any tools that can make this easier?
The current plan is to use ASP.Net WebForms (.Net 3.5). I'd really like to use MVC, but no one on the team knows it including me.
We are not sure yet if we will implement automated testing with the
new one.
Implement automated testing. What's the point in replacing one buggy program with another?
Good question, but "Slowly change" the db structure after getting everyone on the website, sounds like a joke...
I would rather take the opportunity to create a fresh db structure, write a bulletproof migration script for you db, that you can try out and rewrite a zillion times without any side effect fro your clients, and then write whaterver you want (fat/web) on the new db, have it tested and migrate everyone when it's ready.
I have a couple suggestions:
1) create a service layer to abstract away the dependance on the DAL. In a situation as you describe having a layer of indirection for the UI and BLL to rely on makes DB changes much safer.
2) Create automated tests (both unit and integration), especially if you plan on making fairly significant changes to the Domain or Persistance layers (BLL/DAL). To make this really easy you should always try to program to an interface. This makes your code more flexible as well as letting you use mocking frameworks (Moq is one I like) to ensure your tests truely are unit tests and not integration tests.
3) Take a look at DDD (http://domaindrivendesign.org/) as it seems to fit pretty well with the given scenario. At the very least there are some very useful patterns that can help make your application more flexible.
4) MVC isnt very hard to learn at all, it is however an easy way to get unit testing setup for the UI as a result of the MVC architecture (testing the controller and not the view). That said, there is no reason you couldn't unit test web forms, its just a bit more work. MVC really is just a UI framework/design pattern (more Model2 but we can ignore that for now). It gets you closer to the metal so to speak as you will be writting a lot more HTML and using a Model (the 'M') for passing data around.
For DDD take a look at Eric Evans book: http://www.amazon.com/Domain-Driven-Design-Tackling-Complexity-Software/dp/0321125215/ref=sr_1_1?s=books&ie=UTF8&qid=1317333430&sr=1-1
Hope that helps
ASP.NEt forms is a no starter, is completely inappropriate for something like this. I recommend to start with something like Creating an OData API for StackOverflow including XML and JSON in 30 minutes, then build your Web app on top of that (ie. push it to the client, use JQuery/Silverlight).
i.e. Is MVP still the next best choice when MVC is not an option?
I thought I'd ask this here as I'm sure there are others like me who don't have the luxury of being on a green-field project and want to refactor a webforms UI to better separation of presentation from business objects...
I'm working on a legacy application tasked with adding relatively small additional requirements, enhancements, and bug fixes.
The part of the application I'm addressing here may be characterised as the UI for a set of CRUD operations over business objects that are persisted to a relational database.
The existing UI uses a MultiView control to navigate between the editing of associated business objects (one-one associations or one-many / parent-child). Yes, that's right - all on one page. Unfortunately there is very sparing use of UserControls so the markup and code-behind is hundreds of lines long.
On each View a FormView manages the CRUD over the business objects via various ObjectDataSources. Within the ItemTemplate of each FormView various server controls databind to fields or methods on an ObjectDataSource.
I'd like to introduce more separation of concerns and get some of the reams of code out of Page code-behind.
My research so far suggests to me that I might consider:
Use a flavour of Model View Presenter; more specifically - use an ObjectContainerDataSource from the Web Client Software Factory to make it easier to bridge between the current UI and a set of new Presenter classes.
Build again from scratch with an MVC framework (not an option).
Leave well alone; an MVP pattern is only justified if I need to re-use my Presentation in different UI scenarios?
If I settle with (3) I'd still like to know how to start refactoring towards better separation of presentation.
What would you do? any other ideas gratefully received...
Here's some more background for anyone who's interested:
The domain is in pharmaceutical research but that's fairly irrelevant and you can think of it as pretty typical line-of-business - user configuration of a family of settings that form the operating conditions of another part of the application.
The business object layer has already been built in a very consistent manner. Although I may not like it, I can't neccesarily justify changing it. Each object is it's own Repository / Data Access Object in that there are static methods for 'get by ID' and 'get list by criterion'. Where possible common operations are implemented in an abstract base class. Each business object delegates the data access work to a Data Access Layer that makes use of ADO.NET 2.0 Provider Factory mechanisms to remain relatively abstracted from a concrete Provider. In this respect it shares a lot in common with any app that uses the Data Access Application Block from the Microsoft Enterprise Library.
There are fairly exhaustive integration tests written in NUnit that set up a test database from scratch so they take ages to run but at least they verify that stuff works as it should (at some point in the past anyway ;-). There is almost no true unit testing in place (yet).
WebForms now has an emerging effort in the form of the ASP.NET Web Forms MVP project
"...there are still a host of
compelling advantages to ASP.NET Web
Forms.
The ASP.NET Web Forms MVP project is
... an approach that facilitates
separation of concerns and testability
whilst maintaining the rapid
development that Web Forms was built
to deliver"
Rob Conery has concerns that this may be a wasted effort and an unneccesary distraction now that we have MVC but at this stage I still think the source code is worth a look...
http://haacked.com/archive/2006/08/09/ASP.NETSupervisingControllerModelViewPresenterFromSchematicToUnitTestsToCode.aspx has a good example of doing MVP with webforms. The advantage is not just that your UI is decoupled from BL - the real treat is that you can write tests for the code.
One of the common questions asked regarding ASP.NET MVC is why should you use it over ASP.NET Web Forms? The answer generally includes ViewState and clean URLs, amongst others. Towards the end you'll find a blurb about using the right tool for the job and that they serve different purposes. However, I don't believe I've ever seen what those purposes are. So, when would you actually choose ASP.NET MVC over ASP.NET Web Forms, or ASP.NET Web Forms over ASP.NET MVC?
You don't choose ASP.Net MVC over ASP.Net, because ASP.Net MVC still is ASP.Net. You do choose ASP.Net MVC or ASP.Net Web Forms, and there are lots of good reasons to do that:
Easier to get control over your HTML
Easier to do unit testing
Few "Gotchas"
On the other hand, Web Forms do have a few points in their favor:
Easy to put simple CRUD/business apps together extremely fast
Hard to beat ViewState performance in local LAN environment
Easy to learn forms paradigm
The result is that if you're building business apps in a corporate LAN environment (which honestly is still most web developers), Web Forms is really great. In that sense Microsoft really knows their market. But if you're building an app for the public internet, you might want MVC so you can test thoroughly and be sure your pages aren't bloated with unnecessary ViewState or JavaScript data.
Additionally, something that has changed over the last several years is that even many corporate intranet applications now need to support home/remote use, making MVC more attractive to that crowd than it had been.
Use MVC if all your team members are skilled enough to manage "control over HTML", otherwise your code will turn into a tag soup.
In other words
bool useMvc = true;
foreach (TeamMember member in team.Members)
{
useMvc = useMvc && member.IsSkilled;
}
http://weblogs.asp.net/shijuvarghese/archive/2008/07/09/asp-net-mvc-vs-asp-net-web-form.aspx
check that blog !
Bottom line "separation of concerns"
I'll give you a couple purposes, with clear advantages.
If your purpose is a public facing website that will be banking on traffic, use MVC. It is optimal for search engine optimization.
If your purpose is an enterprise web-application that acts like a desktop app, I would lean towards web forms, since state management and compartmentalization of your resources into underlying server controls offers huge advantages if used correctly.
The biggest problems facing developers is managing complexity and keeping code "clean". MVC gives the developer the reins to leverage OOP to tuck away complexity and make code easy on the eyes.
Webforms will be faster to develop in the short term, but it doesn't lend itself to long term sustainability in terms of maintenance and growth.
I've worked with Web forms for 13 years and MVC for 2 years now and when I started with MVC, I had similar questions. Here are my takeaways.
Most importantly: ASP.NET's latest release is 4.6 and they were moving to ASP.NET 5.0, but MS abandoned that for ASP.NET Core, which no longer supports Web Forms (or even VB.NET). So, that alone might give you your answer when deciding what rabbit hole to go down.
That being said:
MVC I'm finding, once you get the hang of it, is WAY easier for dealing with basic forms and any sort of simple "Model", aka tables with a very simple, straight-forward set of relationships such as orders that have tables that link to users, products, etc. Once you start getting into some more complicated relationships and need to return lots of conditional sets of results, rely on parameters, have complicated stored procedures... then Web Forms is much better for dealing with this. If you don't have to deal with this level of complication, MVC makes development SO MUCH faster, especially with dealing with an approach where you already have the DB because it creates so much of the code and validation for you already
If you're not very experienced with database design, MVC does the work for you. It can literally build the database for you.
MVC doesn't have a lot of the built in controls that Web Forms does (Gridviews, FormViews, Sitemaps, Paged lists). Everything has to be written from scratch, but luckily a lot of people have already invented that stuff for you in NuGet which you can just download into your project
MVC relies heavily on the structure of your URL. The path, the querystring, etc. If you find your application needing to do a lot of form POSTing instead of GET-ting, you're going to have to do a lot of tweaking or AJAX posting. If you have a set URL that can't change, it can be a pain. It's doable, but just a little tricker (or you can just use Angular instead).
MVC has no Viewstate. If you need to hide variables from post to post and persist them, it's a little difficult. MVC Does have things like ViewBag which lets you pass data from your controller to your page, but it clears after the page is rendered. There is also something called "Tempdata" which acts like Session state, but more temporary. However, it relies on Session State which is not an ideal way of persisting data. Session variables and tempdata variables are fine for user-level data (profile information for the person logged in), but having two different tabs open by the same user can cause these session/tempdata variables to overwrite each other when you're dealing with the actual model data.
If you're at a crossroads, I'd go with MVC. MS is pushing it and support for Web Forms will likely start going away
Last week at Mix '09, the final version of ASP.NET MVC 1.0 was released.
Some of the stated benefits of this framework are:
Clear separation of concerns
Testability - support for Test-Driven Development
Fine-grained control over HTML and JavaScript
Intuitive URLs
Now, Microsoft are being careful to tout this as being "an alternative, not a replacement, for ASP.NET Web Forms", but given the advantages mentioned above, I'm wondering:
How long will it be until "classic" ASP.NET Web Forms is considered to be a "legacy" framework?
If you were kicking off the development of a new .NET web project today, why would you choose to use Web Forms instead of the ASP.NET MVC offering?
Good questions. I think ultimately, the answer is going to be the development team's expertise and the project needs that will decide that. ASP.NET web forms is so heavily used that it likely isn't going away anytime soon. Plus, there are so many custom controls and third-party support such as components and books. The main benefit of web forms is how easy it is to get a dynamic website up and going. It really is a RAD way of developing websites.
However, once that team has more experience with creating larger websites with much higher demands in terms of scalability, reliability, and test-ability, then they will look towards other solutions for that. In this case, they will realize that web forms are harder for unit-testing. They may also see that viewstates reduce performance and look for possible solutions.
Although MVC has the stated benefits, it is unlikely that anyone will convert their sites to use this new framework right away or ever. Plus, it requires the team to learn the new technology, and work out the new bugs. The team will have to learn new ways to do the exact same thing. For example, how easy is it to support uploading a file using MVC?
As I saw recently, there isn't a reason you can't create a site using MVC and web forms together. So you may see more hybrids in the near future. But I doubt that web forms will ever go away.
I kind of think about web forms like the way VB1 changed the way Windows applications are created on the desktop. To this day, the RAD way of creating application still exists and will never go away.
Keep in mind that MVC STILL uses WebForms for it's default View Engine. Sure, you can replace it with another one, but WebForms is still a core part of it.
Also, not everyone prefers to tightly control the HTML or the Routing. That's not my attitude, but some people just want their job done with the smallest effort.
And aren't .asmx Files technically part of the "old" Model as well? I can say for sure that a lot of people would not like to see them go away.
Still, I personally see ASP.net MVC becoming the main Web Engine for ASP.net in the future, although not in .net 4.0 yet.
You're asking when a newly-released web platform, ASP.NET MVC, will replace Web Forms, which has been around for seven years.
If we'd been crying out for ASP.NET MVC for the past seven years, then it wouldn't have taken seven years before ASP.NET MVC was released. The fact is, not everyone sees a need for this. Many of us have been creating complex, highly-scalable web applications for most of those seven years.
We even knew how to make them testable, and to separate presentation from business logic and data access. ASP.NET MVC may enforce this separation, but I've done it by using coding standards and code reviews, and by saying, "there's no unit test for that", and "get that business logic out of the UI".
Also, if I really needed more control of the HTML, I would write my own control to generate the HTML.
I do not believe WebForms will ever retire.
I've been using WebForms at work in business applications and MVC at home for some private things. Though I really like MVC I do not see how this could be possible to implement really complex UI logic with HTML/CSS/JavaScript. It will quickly become unmanageable and will be quite unsecure since JavaScript can be switched off to prevent disabling some controls or hiding some information. On the contrary, turning off JavaScript with WebForms will virtually turn the page dead for any action, either authorized or not.
Both platforms will continue to evolve. For general web sites and HTML/CSS lovers MVC is a way to go, with complex applications you would want object-oriented architecture and artificial event handling even though it abstracts you from the stateless nature of HTTP.
So, pick up what is best for you.
P.S. Dropping WebForms altogether will jeopardize the future of numerous projects and companies throughout the world. Microsoft folks would not want to become an object of hatred and the trigger that started the third world war.
WebForms will still have a place for those that want a pseudo-stateless web application that they can easily put together by dragging and dropping. For those that don't have to or want to understand how HTTP works. It's the ultimate in RAD for web applications.
ASP.NET MVC on the other hands allows much more finer control at the cost of more responsibility. You get complete control over your HTML however that means you have to sanitize/encode your output yourself. Your application for the most part has to be completely stateless and for some ASP.NET WebForms/Windows WinForms developers that it's a bit hard to wrap their mind around.
I don't think either will ever dominate the other though one may be favored.