Let's say you have an intranet development team where it is in your best interest for each developer to be happy with their work - one person leaving will negatively impact the others. Some developers wish to embrace the Web (i.e. ASP.NET MVC). Others wish to work in a stateful environment where Web is merely the medium for delivery (i.e. SilverLight).
I don't want to argue the merits of either (I have my opinion). Rather I want suggestions for legitimate arrangements such that we can have our cake and eat it too. Is it possible for some members of the team to work with SilverLight while others work with ASP.NET MVC without ending up in pandemonium?
I'm thinking that MAYBE we could have ASP.NET MVC for the majority of our applications and then have the SilverLight people develop components that can be used in the UI? But according to this question that didn't turn out so well.
I'm just looking for a scenario that would allow the team to effectively use SilverLight and/or ASP.NET MVC in their work (not necessarily in the same app) without imploding.
Any links to articles with information pertaining to how well a given scenario works would also be appreciated.
Unfortunately you can't make all of the people happy all of the time.
...which is what it sounds to me like you're trying to do. You have to pick the best technology that suits your application and roll with it. Trying to mix and match technologies just to keep people that want to use one or the other is going to fail.
If your application has legitimate uses for both ASP.NET MVC and Silverlight, then by all means give the Silverlight development to the people that want to do it and let the ASP.NET MVC people handle the rest. Just don't introduce Silverlight to give the developers who want it something to make them happy.
We have a mixture of Silverlight and regular ASP.Net on my team. It's a pretty big application but about 50% of it is Silverlight apps. People who want to work on Silverlight do that and the rest of us do web development. There is one big .sln that has all the projects and a bunch of smaller ones that have projects related to specific functional areas in the app. We have a build process that compiles everything and puts it all together.
Which parts of the application are SL and which parts of the app are HTML depends on a combination of business requirements and end user capabilities -- NOT whether the dev just want's to do SL or HTML.
If you want both do co-exist in your environment, you will need a process and it should revolve around business requirements and not just what fun toy a dev wants to use.
I think you should re-examine your assumptions. In particular:
One need not develop with MVC to embrace the Web; Web forms + Ajax works great in many scenarios.
Silverlight apps don't need to be stateful. In fact, Silverlight apps don't even require a UI.
IMO, the best approach is to start with a detailed architectural design for your site, and to look carefully at where each technology might be best applied. With an architecture in-hand, you can begin design and agile development, and let developers choose which areas they would prefer to be involved with, subject to overall project management constraints. But the key is to have the architecture drive the technology choices, not the other way around.
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.
A little Background:
I started my career almost 5year ago as a web developer using ASP.net and C#, after working as a web developer for only a year i switched to the world of low level programming (i.e C/C++).
Now, from last 4 years i have been working in c/c++
At present i have been assigned a task to develop a large scale web application (by large scale i mean large number of users probably in million and huge communication among those user like communication at twitter or facebook and obviously a huge backend database aswell).
Since i worked in ASP and C#, so i will prefer to develop this application using ASP.net and C#
My Question:
Currently the project is in requirement gathering phase and in the meanwhile i am assigned a task to design its architecture. Now i google various architecture resources and came across following:
MVP
MVC
Three Tire Architecture (One which i use 5 year back)
Please mention some more, if there exist coz i only find those 3
Now i am totally confused with first two because some site mention that if i use MVC then i am not allowed to use WEb forms, and many more . . .
Secondly some sites also mention SOAP and REST but i feel that i am not able to use with ASP.net and C# (with the .Net Framwork 4.0)
What i Want
First, i appologise in advance coz i feel this all confusion arise because i have experience in C/C++ rather than web development.
Secondly, i know that no one did the job done for me and even i don't want to do so, i only need good guidence i.e where to start with, what resources should i study etc.
This site is build on MVC.
MVP is more suitable for older ASP.NET technology like WebForms, but can be a pain.
Three Tier Architecture is more a overall system architecture where you have a database, service exposing database, and consumers using the database. Sometimes it also refers when you separate your app in three layers, like data, business and presentation. MVC and MVP are just UI patterns.
Now, you want someone to tell you what to use, which is impossible, because we have only tiny piece of picture. However, I would always prefers MVC and heavily object-oriented practices when designing the application, except when something to be put fast is to be made.
The Internet is full on tutorials on all these technologies, you should familiarize yourself first with them, and then decide which one to use.
I'd like some vague guidelines about the relative effort to build using ASP.NET versus Silverlight/WPF. I know, it all depends, but any input greatly appreciated.
I'm rebuilding a winforms app and planning on moving it to either:
ASP.NET (could be MVC or webforms), or
Silverlight (4) or WPF with ClickOnce deployment.
It's a typical business-style app with some tens of forms, various datagrids, standard windows controls, etc. Some chart graphics but no multimedia. It's not very data-heavy, i.e. there are quite a few datagrids but they'd seldom have more than 10 cols & 100 rows and usually less. The logic is currently tightly coupled with the winforms code so either way it'll need to be split out from the UI. We also use Crystal Reports for reporting.
The 2-3 developers who will be working on this have some WPF & ASP.NET experience but not much.
I'm tempted to use Telerik controls or similar as they look like they make some things we want to do easier.
The app is installed for a customer and only used internally within their firewall. The main advantage to ASP.NET would be deployment, but I figure that silverlight or wpf with clickonce wouldn't be much worse for deployment and may be faster to build.
If there's any other general information I can provide which will make it easier to estimate relative effort, let me know!
thanks.
UPDATE:
Let's assume the only basis for my decision is the speed/productivity of development (i.e. ignore deployment, UI impact, etc). Which should I choose?
What you use and how cost effective the project will be totally depends on requirements and your team's skill sets. Learning ASP.NET (MVC or WebForms) is typically a long, hard road if you come from a WinForms background (and arguably, if you are doing WebForms, you may as well so Silverlight). If you have a lot of experience with HTML/CSS/JavaScript(jQuery)/MVC patterns, then ASP.NET MVC will probably suit your project better. If you have requirements such as cross-browser compatability, SEO or other weby things, you'll probably go ASP.NET MVC.
On a recent project, where we had an assessment of the requirements and available technology options, we were forced down the ASP.NET MVC by the client but we had determined that given the team and requirements, Silverlight would have been an easier (read: less expensive) technology to implement the application in and it would have reduced the project cost by 50%. (educated, thumb in air guess)
In my experience, the biggest delays are caused by "black holes" - things that you'd assumed were going to be easy when you put together your estimates, which turn out to be hard/complicated/time-consuming due to leaky abstractions, framework bugs, and so on.
I'd therefore favour an approach which uses proven technology and protocols and minimal abstraction, and for me, that would be ASP.NET MVC. But make sure your developers understand HTTP, HTML, the model-view-controller pattern and the fundamentals of stateless architecture.
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.
If yes, when? and how much time do you think that the process will take to migrate your current projects (if it's the case)?
ASP.NET MVC is not meant to replace WebForms. They are different technologies and are designed for different purposes.
Making a blanket statement of saying that I'll only use one and not the other is a very narrow minded approach, as you're missing the pros and cons of each technology.
Microsoft is commited to both technologies going forward and there are quite a few sweet new features coming in WebForms 4.0.
I'll be using WebForms and ASP.NET MVC, but looking at the needs of the current project so that I make the right decision for the current implementation
I've been using it for a few months now. I absolutely love MVC. Converting existing projects may not be realistic, depending on available time. As I see it, Web Forms simulates windows forms development for the old VB crowd. While MVC doesn’t pretend it’s something it’s not and follows the Http process more closely.
A few plusses I see in MVC
1) It’s testable with unit tests
2) Direct control over Html. We make websites, how do we accept not being able to control all our html?
3) No viewstate baggage
4) No control tree to waste time rendering
5) Automatic binding of a modal from a form post
6) It can be rather sexy
And a few disadvantages
1) No more web controls (and many rich 3rd party controls are lost)
2) Slower to develop in
3) Large learning curve
4) Still in Beta (CTP soon though)
Yes for my new projects. But not for current production software.
Yes, in as orderly a fashion as possible.
MVC opens .NET up to the world of Best Practices for Agile development. It specifically addresses concerns about Separation of Concerns, and coupling/cohesion. It also lets us write more-portable software without creating a dependency on any vendor-specific references or components.
It unquestionably is a successor to WebForms, along with WPF, regardless of whatever PR you might read.
The Wikipedia entry is pretty clear, even before being updated for Microsoft's MVC.
Assuming you prefer ASP.NET MVC to Web Forms, it's worth it for a system that's in active development/maintenance.
They can coexist side-by-side, so it's possible to migrate parts of the application (new ones, or selected old ones) and see how it works out. If it's a success, keep going.
An "all or nothing" migration could be disastrous, though - investing a lot without quick feedback is a huge risk.
WebForms are for rich UIs
These can be done just the same with MVC or Webforms. A year from now rich MVC based toolkits will arrive (technically they're already here if you like YUI, ExtJS, etc.) and make this argument null and void.
migrate your current projects
Migrating an existing WebForms project to MVC doesn't make a lot of sense. What are you going to gain? Using MVC for a new project however can make a lot of sense depending on your requirements.
I was never really fond of WebForms to begin with so getting to work with MVC was like a breath of fresh air to me. I've always much preferred the separation of concerns as I could work on the chunks that I was really good at developing, the logic and the data access, and leave the presentation work to the members of the team who had that natural ability. I think the MVC library makes it easier for teams to work together on individual pages as one person can work on the controller and the other person can work on the view.
All that being said, when I'm working on projects where I don't need to focus as much on the coding and it is more display oriented, I still go back to the WebForms because they are so much easier to implement and get up and running. Both have their places and I don't think one will ever supersede the other.
I've been using ASP.NET MVC for several months now and I prefer it to Web Forms. However, I don't see myself migrating my existing projects to MVC. For me, it would be rather pointless. However, all of my new ASP.NET projects will (or should be) developed using MVC, as it is a much better (and more flexible) framework.
Personnaly I restricted ASP.NET MVC for lightweight Front Office Web Sites.
But still using ASP.NET WebForms for Righ BackOffice Applications to take advantage of rich custom controls and some of other nice features of Web Forms.
Another plus for mvc is that javascript like jquery is much easier to implement, so if you plan on using a lot of js, mvc might be the way to go.
No, there's no reason to. It's an alternative style, one I am not fond of. But that's just my opinion; a lot of people like it and I hope it works well for them.
As already said, they're not mutually exclusive, and I play to make good use of both.
IMO MVC is better for web sites, while WebForms are better for web applications.
For example, this site is a perfect showcase for where ASP.NET MVC is a good choice because of the nature of the site and what needs to be accomplished; other good examples would be a web store, or a project management site (like Basecamp), or a social network.
If you were developing a corporate CRM/ERP system, however, I'd stick with WebForms to get rich controls and a more "desktop-like" programming model, since a CRM application is traditionally the domain of a desktop application.
ASP.NET MVC fits my desired style of development better, but I'm wary of trusting myself to it whilst it's not been RTM. It also is different enough that our legacy code will not work with it. If we had been practising Domain-Driven Development things might have been easier, but ...