Silverlight and ASP.NET MVC living together in the same team?

Question

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.

Answer 1

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.

Answer 2

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.

Answer 3

I think you should re-examine your assumptions. In particular:

1. One need not develop with MVC to embrace the Web; Web forms + Ajax works great in many scenarios.
2. 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.