Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking us to recommend or find a book, tool, software library, tutorial or other off-site resource are off-topic for Stack Overflow as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it.
Closed 8 years ago.
Improve this question
I am new to asp.net mvc. I have lot of experience in asp.net web forms. Can any one please help me find a good resource to getting started with MVC 5?
I learned .NET MVC by watching videos on Pluralsight: http://beta.pluralsight.com/. I have also learned a ton by reading posts here on Stack Overflow. There are also a lot of good learning resources on the Microsoft ASP .NET MVC site: http://www.asp.net/mvc.
In addition to all the great answers, I would like to add a few things...
As a consultant working in many different companies, I’ve had my chance to get my hands dirty on many different asp.net MVC applications.
One of the first things I realize is that people’s understanding (or lack thereof) of asp.net MVC varies a lot and this has a major impact on the way the application is built and maintained.
For the past 13 years or so, Microsoft has been teaching us how to build websites using webforms. That is by dragging and dropping controls, double-clicking it and code against that.
When asp.net MVC was first introduced (a while back), people’s initial reaction was to not fully understand why we’d want to intermingle server-side code with HTML. After all…isn’t this bad/wrong?
More importantly, people would compare this to Classic ASP and believe this is some sort of step back.
Now that more and more people have been working with asp.net MVC, I can assure you that most of them would not return to the webform style of things.
You have to understand that an asp.net MVC project is very versatile and with that versatility comes more responsibilities. It is the understanding of those new responsibilities that people don’t fully grasp. In turn, this can easily transform an MVC project into a bunch of spaghetti code and maintenance hell.
As a quick example, I’m still seeing people not understanding or seeing the benefits of having strongly typed Views with ViewModels. Applications have the tendency of evolving and change a lot. Having ViewModels will help in coping with the scalability of your application and when you need to refactor.
Try to adopt a JavaScript standard perhaps with namespace and what not as you’ll quickly see your Views contaminated with JavaScript.
Adopt the separation of concerns philosophy by having a well layered architecture not only for testability but also for ease of refactoring, maintainability and readability of your code.
As an example, download some existing application such as the open source NopCommerce project. Open the source code, see how they do things.
I think the best place to start is http://www.asp.net/mvc and also check
this PluralSight course and also Scott Allen has lots of fantastic materials on is blog google is always the best friend.
Related
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 7 years ago.
Improve this question
I have an web site built in ASP.NET. It is a business website that works with a lot of data.
I had a lot of problems, especially of speed and effectiveness, so I did what I can with ajax, and speed greatly improved.
I wonder if I should switch the web site to ASP.NET MVC?
I don't know ASP.NET MVC very deeply, so I want to know if I should invest in it, the main question is: Is ASP.NET MVC faster and more effective than regular ASP.NET?
I believe that ASP.NET MVC is (if not, already has) becoming the mainstream way to develop websites in using the ASP.NET stack. There is a lot less emphasis on ASP.NET WebForms in the last few years, which hints that MVC is the sensible choice for starting new projects (Note: WebForms is still a popular choice for some devs though, I'm not saying don't use it ever. There's still a place for it.)
Regards migrating existing ASP.NET WebForms apps, I would be a little cautious. Don't switch to another technology unless you have a very, very good reason for doing so. Depending of factors such as the amount of code, the design, it could take a lot of effort to convert an ASP.NET WebForms project to ASP.NET MVC.
In your situation you mention performance issues, which made you consider moving to ASP.NET MVC. I would look more into why your site is not performing as you would like. Use a profiler to measure which code paths are taking the longest ot execute. There are plenty of sites built using ASP.NET WebForms which perform to high-scale, so I would not make the mistake of moving to another technology in order to solve a performance problem.
It depends on where your current issues are.
Should you learn MVC - definitely.
Should you write new applications in MVC - sure.
Should you migrate old applications - depends.
What's the architecture of the current application?
How much time/resources do you have to allocate to a rewrite vs fire-fighting the existing app?
Is there a clear data or middle tier or is the data access built into each page code behind? Many applications are written so that the front-end can be swapped easily or called from other applications (eg via an API) but many webforms applications (not all) are written without these considerations and so it wouldn't be a swap out but a complete rewrite of the application.
What are the current issues other than "it's a bit slow"? For example I've seen an app that loaded the entire data model into memory for each page - simply changing the front-end would make no difference in this case as the cause of slowness was the data loading. Changing the architecture to load only what was needed significantly increased the speed.
The improvements you can get from using MVC aren't necessarily the business level ones you might expect. There are plenty of sites that go into this in more details, here's some to get you going:
MVC generates (much) cleaner HTML in the output - so pages are easier to develop/maintain and easier for developing UI interactions in javascript.
MVC has a much improved pipeline which can be hooked into, eg for adding action filters.
IoC/DI is hugely easier in MVC
Separates the model/controller code from the view html
Your application users won't care about any of these.
I have the same situation with one of my clients and after learning the MEAN stack and working with another company who made the transition to Nancy. I would recommend doing a REST API with Nancy and a pure front end with Angular or another Javascript front end. This will allow much faster response and flexibility down the road. Plus it will give you more flexibilty if you ever want to expose your API to other apps.
I tried to move from Web Forms to MVC and it was not very easy for me at the time.
You can use Asp.net Web Forms, with more ajax and less post backs and less view state usage if you do not want to move to asp.net mvc.
Asp.net MVC on other hand is very good with light wight pages and capabilities to blend in with client side ajax based solutions. And its architecture supports scale ability.
I think you should definitely take the time to learn MVC, as it is becoming a more marketable skill and future projects are more likely to call for it.
With respect to being faster and more effective, it is somewhat. First off, WebForms have a lot of overhead in order to have this windows-forms-like behavior (which, frankly, has never been a perfect fit for web pages). Second, MVC tends to render HTML that is much cleaner without the view state or long IDs. So those two items can make it faster. (Of course, if you are having speed issues you also need to look hard at your host server.)
With respect to rewriting your current project to use MVC, that's a more difficult question that only you can answer. WebForms still work and will probably be supported by Visual Studio for many years to come. Depending on your project, rewriting it can be a costly task. So you'll need to decide if it's worth it. That said, I hope to rewrite all my webforms websites using MVC as time allows, although part of the reason is just to update the look and make them more responsive to mobile devices.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking us to recommend or find a tool, library or favorite off-site resource are off-topic for Stack Overflow as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it.
Closed 8 years ago.
Improve this question
Ten years ago or so I built a small web site in ASP. I basically wrote it in a text editor and uploaded the files to a web server. I then didn't program anything for the web for a while and now I work in Visual Studio 2012 in C#, VB.Net and ASP.Net. The questions is, is the old ASP I originally worked in still a viable alternative for creating web sites? Would a professional even consider it or has the industry completely moved away from it?
I ask because a large project is going to be started this year for the small company I work for. It looks like it is going to be handed to someone who's skill-set has never moved past the old ASP. He does not do a lot of programming, but is capable at what he does. It seems wrong to me, but I don't know enough about the industry outside my little world to make an argument against it.
Thanks.
I personally do a lot of legacy (there's something to that term) ASP work to support aging infrastructure until it is ultimately replaced (parallel work) by ASP.Net.
While you will find/rediscover "hidden gems" like the now-sexy-again "javascript on the server-side" (yes, you can do Javascript in classic ASP) and yes, you can handle JSON in classic ASP, the term "legacy" is, IMHO, really all there is to it.
Dev support for it today, is likely out of necessity more than anything. Considering it for new development should be the question hard to argue for. Translated to a business question - would you invest new money and resources on outdated infrastructure?
For your dev - it's not going to be a "cakewalk" but he/she will find things still familiar (and much better). Moving from VBScript (classic asp) to VB.Net will likely be the path of least resistance.
The "funny" thing about being "used" to ASP is that it might actually allow your dev to "skip" ASP.Net WebForms and "leapfrog" to MVC and/or WebPages and Razor - re: it's more "bare metal" stuff like it was in classic ASP!
HTH....
I don't really believe that anyone that has kept up with any sort of industry trends would do green field dev in Classic ASP. Using classic ASP just closes off a lot of avenues and makes life harder. Try finding good classic ASP developers? It's a nightmare. There is less and less resources available to help develop. Had the same issues and I took a department over and implemented MVC and customers are far happier. All the things you get for free like validation etc makes for far better apps. Can do TDD easily in MVC and not easily done in Classic ASP. Routing, JSON, clean separation of concerns, loose coupling, modern ORM availability, good IDE, just so many benefits of moving to a modern language.
You can write classic ASP reasonably well but most Classic ASP code I have ever seen looks like Spaghetti.
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 am in the process of architecting an application. It will be a large, enterprise class web application. Thousands of users could upload files, search large number of blog entries with chat functionality and such. It will also have mobile interface. It should be highly testable, scalable and flexible.
I have narrowed it down to three environments: pure play ASP.NET, pure play DotNetNuke (DNN) and a combination of ASP.NET and DNN. To keep this very brief, here are some 'for' and 'against' on each of the options:
ASP.NET:
for: highly scalable, supports patterns like MVC, testable, consistent architecture.
against: long development time.
DotNetNuke:
for: short development time, large number of existing functional modules and skins.
against: architecture is sealed, can't support MVC, unit testing is difficult, inconsistent modules/skins, potential upgrade issues, user experience is inconsistent due to disparate modules from different vendors, poor documentation.
So, the questions are: what do you think? Has anyone switched from DNN to ASP.NET (and, vice versa)? Have you objectively evaluated these two and what did you choose?
Highly appreciate your help. Thanks.
henry.
DNN is ASP.NET, just with a lot of the work done for you.
Also, please remember that just because raw ASP.NET has the potential to be more scalable, doesn't mean that you are actually going to built it to be more scalable. Or that you will built it well in the first place.
It comes down to a trade off between control and resouces/talent. If you have many very talented developers (like, top-10% talent), a lot of time, clearly defined requirements for your site, and consumers who will be patient while you build out the infrastruture, by all means go with raw ASP.NET.
However, if you need to build it quickly and need to be flexible, or you have limited development resources, you might have to sacrifice some of that control and unit testing and potential performance (again, the "potential" part is key here).
Based on what you are looking for, I'd recommend you go with a platform like DNN, or a million other ones line SiteFinity or Umbraco or Orchard or something like that (some of them like Umbraco give you MVC too). It gives you a lot of the infrastructure and plumbing common among a lot of sites, probably done better than you are going to do it, so that you can focus your resources on the truly unique aspects of your application.
Just stay away from SharePoint. It's evil.
I've built raw ASP.NET sites for really customized applications, which was good because I didn't need a lot of plumbing and wanted really unique funcitonality through the site. But then I've built social networking sites with DNN, which worked well because it had packaged components for blogs and forums and chat and all that stuff, plus allowed for easy skinning. I designed another application for a customer that they wanted to have a lot of custom functionality, but they also wanted to updated a lot of content and internatalized it, so we used a Umbraco for that. And right now I have a ASP.NET app that works great, but I want to add in some social features, so I'm going plug in a Umbraco or DNN site that integrates with it to host the more common social components.
I would definitely recommend DNN based on your very limited list of needed features. You can always build a custom module to meet your exact needs or modify an existing open source module as needed. You can use the MVP approach in your module development to improve the testability.
Have you considered the Umbraco CMS? It is built on .Net (v5 is MVC3). It is open source and a very robust and well supported application. It has been used for the asp.net site for example.
It has a very short development time, many modules, extremely flexible and I find it very easy to extend. For example, I rolled my own workflow, event driven publishing and have created multiple custom administration sections for managing bespoke functionality external to Umbraco.
You can use XSLT, Usercontrols or Razor to create template modules.
It has a fantastic community too.
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 8 years ago.
Improve this question
I need to learn and adpot the MVC methodology for building web apps. Which is the better way to go given that I have experience with ASP .NET Webforms - ASP .NET MVC or Ruby on Rails?
I've heard people going gaga over RoR and its simplicity and its features such as scaffolding, ActiveRecord, convention over configuration etc.
However, I fail to see what is so great about these. Most of them sound basic (the kind you'll not really want to use in production code - scaffolding for example) - and most of them sound like they are there in ASP .NET MVC in some form or the other.
Why should I consider learning RoR over ASP .NET MVC?
Are there benefits I do not know about or am unable to perceive?
I suggest you learn both!
I'm a professional ASP.Net developer by day, and a hobbyist RoR developer by night. Learning RoR will in fact make you a better .Net developer, and it's fun!
Also consider that one day you may in fact be able to write an ASP.NET MVC app in IronRuby instead of fussy old c# :)
There are many reasons I would recommend learning RoR over MVC
It's a much more mature stack. It's been around since 2005.
You get to learn a new programming language. "They" say you should learn a new programming language every year.
There is a very rich set of extensions to the base stack. Eg. HAML, Authentication gems, profiling and the list goes on and on.
You get to use database migrations out of the box. Something that is a bit of a breakthrough in database configuration management.
Dynamic languages give you a massive amount of flexibility.
That said: ASP.Net MVC is an awesome framework from Microsoft. I am not advocating dumping your stack and moving to the dark side. I just think it helps to have a broad understanding when it comes to technology.
If you're familiar with the Microsoft stack (Windows, IIS, SQL, ASP.NET) but not so familiar with the Linux stack (Apache, MySql, etc), then going with ASP.NET MVC over Ruby on Rails will cost you a lot less in the long run, in time spent on learning infrastructure.
I suggest you take a look at the job market in your area, and choose what will increase your opportunities. Ruby on Rails is a great framework, but if nobody in your area cares or uses it, then it won't do you any good to learn it (speaking from a career perspective - there are lots of reasons it would benefit you from a learning perspective). I was faced with this dilemma recently and gave it a lot of thought; since my area is pretty much 99% .Net based and that's what companies want, I decided to focus on MVC and becoming an "expert" in ASP.NET instead of learning RoR, since there's no demand for RoR. I actually wasted two months learning RoR before I realized that it would help me personally, but not professionally.
That said, if you're planning on striking out on your own then choose whichever one you feel more comfortable with. If you already know Asp.Net though, I'd recommend taking a look at the MVC framework first since it leverages what you already know, but I heartily suggest looking at picking up Ruby, if not the Rails framework, since it's a very good scripting language for many tasks.
I would recommend learning one at a time. The biggest part of of learning a new language or method of programming is learning the best practices and changing how you approach a programming problem. Not just the syntax. Jumping into two at once will leave you with bad habits in both.
Because you already know ASP.NET I think learning ASP.NET MVC would be the logical next step. Get a solid understanding of MVC concepts and THEN try a project or two in Ruby on Rails. The two frameworks approach some things differently. You may find that your style and preferences fit one better than the other. But either way, now you know both. Can't hurt right?
However, I fail to see what is so
great about these. Most of them sound
basic (the kind you'll not really want
to use in production code -
scaffolding for example) - and most of
them sound like they are there in ASP
.NET MVC in some form or the other.
The ability to rapid prototype a website is part of what makes RoR so popular. When designing a website for a client there's a big difference between a non-functional mock and a functional mock.
I believe the feature gab between ASP.NET MVC and RoR will continue to get smaller. Eventually the choice will come down to a question of Windows vs LAMP.
I would spend a few weeks with RoR. It's extremely simple to get it installed and up and running so you can develop with it. Then it's just a matter of following a few tutorials until you've covered most of the basics. Then decide if you want to continue with RoR or stick with ASP.NET MVC.
if you already know c# and you were working with asp.net webforms, try asp.net mvc...and when you learn it, you can improve your skills with RoR as I am planning to...
cheers
Personally I would invest the time in learning both. I have done this and although I ended up going with MVC for my current project, the decision was because I didn't have the time to invest in learning Ruby language. The RoR framework on the other hand you can get within a few nights and get going with webpages, validation, CRUD e.t.c. in no time at all. However when you need to start adding domain logic, learning about gems you may need to understand Ruby.
Another reason is I already have a hosting setup for Microsoft, and I know c# and the .net framework and the resources I'll need already so although it's less mature and isn't as feature-rich as RoR, I deduced I could get further faster with MVC.
To make the decision yourself, weigh all the options, spend a week with MVC ( use the book MVC in Action ) and spend a week with RoR (use the book Agile Web Development with Ruby on Rails 3rd Edition ) these will get you going within no time. Then when you decide on one or the other you will have a more knowledgeable perspective.
Considering Stack Overflow is written with ASP.NET MVC I think it might be sacrilege to promote RoR over MVC.
MVC has pretty much given Microsoft lovers one more tool that they don't need to go elsewhere to get.
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 2 years ago.
Improve this question
How much of ASP.NET or C# is required for Sharepoint development? Do you need experience with things like developing N layered web applications, design patterns, test driven development, strong SQL background etc?
I hear that Sharepoint development is different from enterprise applications thats typically built with technologies like ASP.NET.
If I know my basics in .NET, C# and have some experience with ASP.NET and have good understanding of things like Page lifecycle in webforms, web parts, Master pages etc, then am I ready for Sharepoint?
Also, is Infopath very heavily used in Sharepoint development?
If you already know ASP.NET than you are ready for SharePoint development. Get familiar with its SDK and other development concepts. SharePoint Dev Wiki might also be a good start.
A must have for new developers is to learn SharePoint from end user perspective. I am using this book to train the new guys. If you do not understand these concepts it might be hard to start coding.
It really depends on what you are wanting to achive, there are more than a few ways to develop something for SharePoint each requires different skills.
for example :
SharePoint exposes a number of webservices which you can use to complete a number of tasks.
A step up from that Sharepoint has a number of DLL's you can reference directly in order to access a more granular level of detail, but is more fiddly to work with.
Neither of these require any knowledge of ASP.NET but both work with sharepoint.
If you are planning on making a WebPart then yes ASP.NET knowlege is a big plus.
If you want to work with the Sharepoint workflows then you need knowlege of WF.
There is no one fit for developing sharepoint, which quite frankly makes it hard to hire people for it.
I guess it really depends on what you mean by SharePoint development. In my humble opinion you must learn what SharePoint provides out of the box in order not to reinvent the wheel all over again.
The object model, web services and how to deploy your work using solutions is something you have to pick up very quickly in order to be a good SharePoint developer.
As I am more of a consultant type when a developer I can't say whether you should know SQL and AD but I guess it won't hurt a bit.
If you are fluent in C# it might also be a good idea to have a closer look at PowerShell as it sure looks like Microsoft will integrate PowerShell in all server products including SharePoint 2010.
I don't think it's much different, really. I've been learning both at the same time to some success. Of course, ASP.NET and SharePoint are just different things, but SharePoint is built on ASP.NET, so to the extent you understand ASP.NET, you also understand SharePoint.