Silverlight和ASP.NET MVC一起生活在同一个团队中？

Question

假设您拥有一个内部网开发团队，每个开发人员都对他们的工作感到满意，这符合您的最佳利益 - 一个人离开会对其他人产生负面影响。一些开发人员希望拥抱Web（即ASP.NET MVC）。其他人希望在有条件的环境中工作，其中Web仅仅是交付的媒介（即SilverLight）。

我不想争论两者的优点（我有自己的看法）。相反，我想要合法安排的建议，以便我们可以吃蛋糕并吃掉它。是否可以让团队中的某些成员使用SilverLight，而其他成员可以使用ASP.NET MVC而不会陷入混乱？

我在想，我们可以为大多数应用程序安装ASP.NET MVC，然后让SilverLight的人员开发可以在UI中使用的组件吗？但根据this question并没有那么好。

我只是在寻找一个方案，允许团队在他们的工作中有效地使用SilverLight和/或ASP.NET MVC（不一定在同一个应用程序中），而不会发生爆炸。

任何指向文章的链接都包含有关特定场景运作情况的信息。

Answer 1

不幸的是，你不能让所有人都满意。

......就像你想要做的那样，这对我来说就是这样。您必须选择最适合您应用的技术并使用它。尝试混合和匹配技术只是以保持想要使用其中一个的人失败。

如果您的应用程序具有ASP.NET MVC和Silverlight的合法用途，那么无论如何都要向想要执行此操作的人员提供Silverlight开发，并让ASP.NET MVC人员处理其余的事情。只是不要引入Silverlight来给那些想要它的开发者一些让他们开心的事。

Answer 2

我的团队中有Silverlight和常规ASP.Net的混合体。这是一个非常大的应用程序，但其中约50％是Silverlight应用程序。想要使用Silverlight的人这样做，我们其他人都进行Web开发。有一个大的.sln包含所有项目和一些较小的项目，这些项目包含与应用程序中特定功能区域相关的项目。我们有一个构建过程，可以编译所有内容并将它们组合在一起。

应用程序的哪些部分是SL，应用程序的哪些部分是HTML取决于业务需求和最终用户功能的组合 - 而不是开发人员是否只需想要来执行SL或HTML。

如果您希望两者在您的环境中共存，您将需要一个流程，它应该围绕业务需求而不仅仅是开发人员想要使用的有趣玩具。

Answer 3

我认为你应该重新审视自己的假设。特别是：

1. 不需要开发MVC来拥抱Web; Web表单+ Ajax在许多场景中都很有用。
2. Silverlight应用程序不需要是有状态的。实际上，Silverlight应用程序甚至不需要UI。

IMO，最好的方法是从您的网站开始详细的架构设计，并仔细查看每种技术最适用的位置。借助现有的架构，您可以开始设计和敏捷开发，并让开发人员根据整体项目管理限制选择他们更愿意参与的领域。但关键是让架构推动技术选择，而不是相反。