如何构建C#解决方案
本文关键字：解决方案 构建 何构建 | 更新日期: 2023-09-27 18:15:28
可能重复：
命名空间/解决方案结构
如果我正在创建一个大型C#应用程序，我应该将其全部保存在一个项目中吗？
我计划拥有一个数据层和GUI层。这些应该在一个项目中，还是应该分成两个项目？在这个阶段，我认为所有这些都应该在一个项目中，因为你可以有一个单独的类文件夹来表示数据层，并在需要时实例化它们。
假设我有一个单独的数据层项目，这个项目(以及DLL(应该叫什么？我不会称之为<ProductName>_DataLayer.DLL。你永远看不到。
还有其他重要问题吗？降低主.EXE的大小重要吗？
我个人对这个话题的最爱：Scott Hanselman，Mike Roberts
您应该将这些层作为同一解决方案中的独立项目，例如数据层将是类库项目，它可能被命名为YourProjectName.DAL，例如ProductName.DAL.DLL或DataLayer
始终建议数据和GUI分离，您永远不知道将来需要对数据层做什么。
我使用.Data.UI命名约定，这很好。
我肯定会在自己的项目中保留单独的层。根据应用程序的大小，我还建议将其进一步分解为基于功能的逻辑分组。
你可以随便叫它什么。可以在项目的"特性"窗口中将程序集名称设置为与项目名称不同。
您必须考虑是否要在多个项目之间重用数据层。如果答案是肯定的，那么你应该把它放在一个单独的项目中。
如果没有，那么将它与GUI分离可能仍然是明智的，以防出现您没有想到的场景。(例如，您决定创建Web服务(
命名：对于命名约定，我更喜欢DATA和UI。
如果解决方案变得非常大，您可以考虑使用"解决方案文件夹"。
更简单的方法是将所有项目都放在同一个解决方案中。
但是，如果你有很多项目——这些项目是很久以前创建的，但没有修改(或者修改的情况很少见(——最好将它们从解决方案中排除，将DLL移动到一些常见的文件夹中，并用作解决方案中的DLL引用。
对于名称，我们使用点分隔-例如<项目>。dal.dll
同一解决方案中的不同项目是一种很好的方法，但这实际上取决于项目的使用方式。
在某一点上，通常有一个ProjectName.UI>ProjectName.BLL>ProjectName.DAL体系结构，然后创建一个模型项目来定义数据契约，以便在层之间移动数据。
BLL=业务逻辑层DAL=数据访问层
每个层都被编译成不同的程序集，并为您的接口提供EXE。编译后的EXE文件的大小并不是一个真正的问题，但更重要的是要使体系结构正确——如果你为每一层都有一个单独的项目，这将使你的部署更易于管理。
现在更常见的是使用Repository模式体系结构，它非常适合使用ORM。如果你想要易于开发和重构的可测试的、基于组件的代码，你绝对应该考虑使用存储库。