Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I want to create a website for bookstore and I'm confused which one should I use either ASP.NET WebForms or MVC?
Can anyone have idea which is efficient and will provide better throughput?
I know Microsoft has said "ASP.NET MVC is not a replacement for WebForms". Some developers say WebForms is faster to develop than MVC, but I believe this all comes down to comfort level with the technology; so I don't want any answers in this direction.
Given that ASP.NET MVC gives a developer more control over our application, why is WebForms not considered obsolete? When should I favor WebForms over MVC for new development?
You don't have to make that decision right now.
In VS 2013 you can mix and match WebForms, WebAPI and MVC, even in the same project:
http://weblogs.asp.net/scottgu/archive/2013/10/17/announcing-the-release-of-visual-studio-2013-and-great-improvements-to-asp-net-and-entity-framework.aspx
I found this answer on web and found helpful , so I though I should share this with you. :)
Webforms vs. MVC seems to be a hot topic right now. Everyone I know touts MVC to be the next great thing. From my slight dabblings in it, it seems ok, but no I don't think it will be the end of webforms.
My reasoning, and the reasoning as to why webforms would be chosen over MVC, has more to do with a business perspective rather than what one is better than the other.
Time/money are the greatest reasons why webforms would be chosen over MVC.
If most of your team knows webforms, and you don't have the time to get them up to speed on MVC, the code that will be produced may not be quality. Learning the basics of MVC then jumping in and doing that complex page that you need to do are very different things. The learning curve is high so you need to factor that into your budget.
If you have a large website written all in webforms, you might be more inclined to make any new pages in webforms so that you don't have two very different types of pages in your site.
I'm not saying it's an all or nothing approach here, but it does make your code harder to maintain if there is a split of both, especially if not everyone on the team is familiar with MVC.
My company recently did three test pages with MVC. We sat down and designed them out. One issue we ran into is that most of our screens have the View and Edit functionality on the same page. We ended up needing more than one form on the page. No biggy, except then we wouldn't use our masterpage. We had to revamp that so that both the webforms pages and MVC pages could use the same masterpage for common look and feel. Now we have an extra layer of nesting.
We needed to create a whole new folder structure for these pages so that it followed the proper MVC separation.
I felt there were too many files for 3 pages, but that is my personal opinion.
In my opinion, you would choose webforms over MVC if you don't have the time/money to invest in updating your site to use MVC. If you do a half arsed approach to this, it won't be any better than the webforms you have now. Worse, you could even be setting this technology up for failure in your company if it's messed up, as upper management might see it as something inferior to what they know.
Related
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 7 years ago.
Improve this question
I have an ASP.NET MVC 4 project and I'm stuck on an architectural decision on which JavaScript framework or library to use Angular.js or Knock.js. I am currently leaning towards using Angular.js over Knockout.js, but don't want to find out midway during project development I made a mistake.
Here is some background:
We need two-way model data binding
We need the ability to test views. I want to be able to do end to end unit testing. Also, we are using continuous integration.
"Save Changes" functionality. i.e. if a user makes changes on a page we need the ability to detect any changes and prompt the user to save their changes before they navigate away from the page
"Notifications" functionality. i.e. user will be logged on approximately 8 hours and will need to be notified and updated of changes made by other users (errors, data status changes and the like)
We need to "future proof" our application. Currently the business unit hasn't decided if we will need to support mobile devices, but I know it's just a matter of time.
Our team consists of developers with varying experience levels from very junior to senior developers.
Currently our models are complicated and may get even more so
We need to also consider RAD, code reuse, and maintainability
I have read the excellent answer here and watched Scott Allen's interview about Angular here
Since we are unable to change from our current ASP.NET MVC 4 architecture to use something on the server side like Web API I have some concerns in trying to implement Angular.js with MVC 4. Will this cause us to have two models one on the server and one on the client?
I am not looking for a "which is better" discussion about Angular and Knockout because I think they both have their pros and cons. I am looking for actual code on implementing a JavaScript framework or library in an ASP.NET MVC 4 application. I need a solution that I can live with 2+ years from now :)
Any ideas or suggestions? Maybe the answer is not Knock or Angular, but some other JavaScript framework?
my 2 cents worth.
preamble - i have worked with both angular and knockout.
I'm on my 3rd non trivial front end built with a MVVM/MVC lib.
I started with knockout because its MVVM is very similar to the wpf/silverlight mechanics. And it works well. The tutorials and documentation are top notch. All your coders will be able to work with knockout.js within days or if they have used mvvm under .net, then within hours.
However, these days I am using angular and will probably stick with it for the following reasons.
angular is a complete framework - knockout is really about just the 2
way binding. you still need other libraries like backbone.js/jquery
to do the rest of your work.
angular has dependency injection. which is perfect for adding
mocking for testing as well as giving structure to your code.
angular treats normal JS variables as observables within its $scope
object. that means you dont have to declare them in a special way
I'm not an angular fanboy, i still think they could move more over to the MVVM architecture instead of the "funky" MVVM/MVC hybrid architecture they currently have.
The biggest problem with angular is the documentation. Compared to knockout, it is woeful. It will add additional time and cost to getting your coders up to speed. Once they are there however, it is currently the best choice IMHO.
Glad to see this questions was of interest to the community ;) Just for completeness here's what I ended up doing:
I did go with AngularJS and ASP.NET MVC 4 and was glad that I did. Although, Angular has a steep learning curve but its worth it because of the power of directives.
We need two-way model data binding - On occassion I needed to set some initial values coming from the MVC controller. I used the ng-init attribute to accomplish this.
We need the ability to test views - I followed the AngularJS docs for testing
"Save Changes" functionality - I implemented this using a directive in Angular
"Notifications" functionality - I implemented this using toastr.js and and directives (schweet)
We need to "future proof" our application - I don't know Google's plans for AngularJS, but after working with AngularJS I can't see it going anywhere anytime soon and expected it to become more widely adopted :)
I don't have a lot of input on AngularJs, but want to provide some thoughts on Knockout.
Knockout is primarily a data-binding library to connect views to view model, but doesn't really provide a lot of capabilities beyond that. I wouldn't recommend using knockout alone as the main library to build a complex client-based web site.
You didn't mention whether you're implementing spa-like functionality (i.e. hash-tag navigation) or whether you're primarily using MVC server-side views (e.g. Razor). If you're just looking for quick data-binding on a per-page level, I would even reconsider that. To me, both of these (angular or knockout) are designed to enhance the client-side development experience - not so much a server-side approach such as MVC.
If you're considering an SPA approach, even in part, you'll likely want some framework that provides some level of control over the view activation life cycle.
As far as data-binding power and reliability, I believe in Knockout. I have been using it extensively, and have grown quite fond of it. If you like the feel of knockout, you may want to look into Durandal. Durandal is a decent framework is able to meet the needs of many "spa" web projects. It's a client-side framework built on top of several proven libraries, including Knockout. It's a little (lot) more light-weight than Angular, and possibly easier to user.
We are building a fairly large ASP.Net MVC web site using Durandal with Knockout in conjunction with an additional facade to tighten things up from a development standpoint, and the integration with ASP.Net MVC is straight-forward. I don't recommend trying to use the server-side knockout stuff that's out there; I just find that to limit the real power of the MVVM pattern.
I am working with ASP.NET MVC 4, and trying to have areas in separate projects.
I have been checking this thread where we are anticipated the non-supporting state of areas in different projects after ASP.NET MVC2:
What are the pros and cons of Areas implemented as single projects vs multiple projects in asp.net mvc
Anyone know if it is true that it is not supported anymore?
Could anyone help me to find out if there is a common way to have areas in separated projects when using ASP.NET MVC 4?
I have found this other thread that may help, but was looking for a more common way:
ASP.NET MVC 4 Areas in separate projects not working (view not found)
Thank you!
The answer is most likely no, but I can't provide a definitive source as it concerns > version 3.
This was written in 2010:
I'm the development lead on ASP.NET MVC at Microsoft.
There are no plans to include multi-project areas in ASP.NET MVC 3.
However, it's definitely an area that we plan to revisit in the
future.
In the meantime MvcContrib's solutions are probably the best bet. The
MVC Futures download still includes an old (and perhaps only
semi-functional) version of the original multi-project areas feature.
Because the full source code for it is also available, you might be
able to construct a solution that is customized to your needs.
Currently, the areas template as provided in VS2013 does not provide an out of the box solution for this. My assumption would be that it is "possible" but not supported. The greater question would be, what scenario are you encountering where it is necessary to put your areas into different projects?
Different projects are like different sites in one solution. They do not depend on each others. Each Area has own routing registration.
You can check this. May be it will help:
ASP.NET MVC 4 Areas in separate projects
This question already has answers here:
Closed 12 years ago.
Possible Duplicate:
Which to choose: ASP.NET MVC or RESTful WCF?
I'm trying to figure out when I would ever want to use WCF to build restful services instead of something much less complex like ASP.Net MVC? With MVC I can easily control the urls and the output. With WCF there's an increadible amount of know-how and complexity to get things working right.
Maybe this question is argumentative, but I really have a limited understanding of WCF so I'm looking to be educated not start a flame war.
Thanks!
I've used both, and honestly it's much easier/ quicker setting restful services up as mvc actions. The complexity of the wcf configuration files is absolutely absurd and borderline unnecessary. Imo..
For example.. i deployed the same wcf services project on a few different versions of iis, and they simply would not run on one particular configuration. Had to Google around all over just to find out that some silly element had to be added to the web config in order for it to run. Epic waste of time.
Can anyone point me to any self-contained, complete, current reference materials/projects using NHibernate in an ASP.NET MVC2 application?
I have looked at Sharp Architecture, but I am not sure I need the complexity in that project. I certainly don't know enough about it to know if it is over-engineered for my purposes.
I would like to see more types of implementations to gauge the various ways people have skinned this cat.
This video series on nHibernate is great and they are using MVC Storefront as the base for the work:
http://www.tekpub.com/production/nhibernate
Code is here:
http://github.com/robconery/Kona
Another great MVC Resource (if you need one) is their MVC Videos:
http://www.tekpub.com/production/aspmvc
and
http://www.tekpub.com/production/byob
I can't recommend them enough.
Max Schilling
Gave it to Max for just answering. :)
But, for the record, here's additional apps to consider, should you end up here:
Sharp Architecture (the Northwind app
is okay but lean, not typical
enterprisey stuff)
Who Can Help Me? (great stuff and
kept up-to-date)
FubuMVC has good sample apps (based
on MVC not MVC2 at the time of this
post)
Thanks.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
Is it my browser that doesn't work with their API online documentation?
The structure of it seems to be very bad compared to the Java API online documentation and the Yii API online documentation.
I am new to Zend Framework, so I wonder, should it be like that?
I think the API is nice, the only problem sometimes they don't give real meaning of arguments
After the API is maybe a bit behind some java examples, but I find the reference guilde quiet impressive and complete. You've got 900 pages describing every piece of the framework with short code snippet that's just wonderful.
Personally I use more often the reference guide then the API documentation.
I've been digging into Zend Framework for about a month now. I'm starting to catch on but I have to agree with the initial comment. The API documentation, at least what is available, is atrocious. What is this Dojo stuff anyway? I would expect a proper, standardized API reference for something as extensive and powerful as the Zend Framework. For an experienced software engineer the reference manual is really introductory material. Once it is digested all that is really needed is a good API reference that clearly shows properties, methods, inheritance tree, with brief descriptions where necessary. Like Java, AS3, etc. I could have saved myself about two weeks of time had I had full access to the API. I don't get it, but I intend to persevere with ZF.
For me the problem is the reference guide simply lists through all the components and has a massive page telling very long-haul uses of each component with no sort of scope of where said code should appear in your work flow.
I believe it should be re-factored to be like CakePHPs documentation, where each page is targeted at getting a specific task done, like "Saving Your Data", "Deleting Data", "Validating Data" and so on.
Real life examples with context are a lot more useful then the Zend Docs where I tend to have to guess where certain variables (commonly $db) come from - and in full MVC cases, does't even apply.