Silverlight应用项目结构 - 多少钱太多了？

Question

我的团队正致力于创建我们的第一个Silverlight 4应用程序。首先要对实际项目给出一些细节。它将是Silverlight 4，旨在运行Out-oF-Browser，我们将使用WFC将数据服务与我们自己的Dataobjects实现一起使用。 （没有实体框架，LINQ-to-SQL等）。我们有一些顾问正在推荐一个包含超过11个单独项目的解决方案结构。对我们来说，似乎没有理由，任何人都可以看到为什么可能需要以下内容的任何理由？

• Project.Client - 资产，样式，视图
• Project.Common - 转换器，助手
• Project.Data - 未知目的（客户项目）
• Project.Infrastructure - 命令，常量，接口，日志记录
• Project.MajorFunctionA - “应用程序主要功能A的业务逻辑”
• Project.MajorFunctionB - “应用程序主要功能A的业务逻辑”
• Project.MajorFunctionC - “应用程序主要功能A的业务逻辑”
• Project.Models - 对WCF服务的抽象访问
• Project.UIControls - 用户界面的自定义控件
• Project.UnitTests - “潜在的所有单元测试”
• Project.ViewModels - 查看UI的模型
• Project.Web - silverlight应用程序的主机项目 - 无代码
• Project.Web.Infrastructure - 数据对象和WCF服务

现在，我们的主要困惑在于为什么我们不会将事物命名为将它们分开，以及诸如“Project.MajorFunctionA”之类的东西，它只是应用程序的一个小组件，为什么它应该有它自己的项目。 （请记住，该特定函数的Views和ViewModel不会存在于该项目中，而是存在于其他Client / ViewModel项目中。

我们正在寻找一些验证，因为我认为没有任何理由。

Answer 1

同意：将名称空间用于逻辑组织，而不是项目。一种方法是将项目视为部署单位。 Project.Client是否总是与Project.ViewModels一起部署？ Project.Models？是一个引用另一个？只需包含在同一个项目中，并使用命名空间进行组织。

您可能希望将Silverlight类库/应用程序分离到单个项目中的几个原因：

• 重用。您希望开发将用于其他应用程序的API。您的Project.Infrastructure可能属于此类别。
• 模块化。 MajorFunctionA仅在最终用户的20％时间内使用。也许只有某些经过身份验证的用户才能访也许只有在导航到没人去的特定页面时才能访问。您可以选择构建单独的Silverlight应用程序，并仅根据需要使用MEF或PRISM等框架下载.xaps。
• 开发人员工作流程。一个城市/办公室的一个团队正在开发Project.Client，另一个城市/办公室的另一个团队正在开发Project.Models。建立单独的项目以使生活更轻松可能是有意义的。

关于程序集的另一个注意事项是程序集之间不能有循环引用。换句话说，如果ClassA和ClassB在同一个程序集中，ClassA可以引用ClassB，而ClassB可以引用ClassA。但如果他们在单独的集会中，他们就不能。现在，如果你的类有很多循环引用，那可能不是一件好事，但有时很难避免，如果它们恰好位于不同的程序集中，那么你的选项会受到更多限制。但另一方面，增加组件的数量限制了循环引用的机会，这可以提高设计的质量。还有别的东西需要注意。

遵循该逻辑，一种替代方案是将Project.Client，Project.Data，Project.Model，Project.UIControls和Project.ViewModels分组到一个项目中，并将Project.Common和Project.Infrastructure分组到另一个项目中。 MajorFunctions可以单独保存或分组到Project.Client中。你最终会得到：

• Project.Client - 特定于应用程序的界面，视图模型和模型。
• Project.Infrastructure - 通用，可重用的帮助程序，转换程序和接口。
• Project.UnitTests
• Project.Web
• Project.Web.Infrastructure

另外。对此没有真正正确的答案。我正在标记为社区维基。