Question

我们正在使用Visual Studio 2010将Windows应用程序转换为基于.Net的浏览器。虽然我不是.Net的新手，但我不熟悉基于3层架构的应用程序。我想为数据库中的每个表创建类，并将它们放在命名空间下。类名将与表名相同，因此Namespace中的每个类都将被引用为类似CompanyName.ProductName.Entity。{table name}。现在我的问题：

这可行吗？

我会为每个表类创建单独的项目吗？请注意，随着更多程序的转换，将创建新的表类。

这会创建一个巨大的.dll吗？

其他开发人员如何访问我创建的类，以及它们存储在哪里，以便我可以使用Using指令引用这些类？

Answer 1

始终使用单独的cs文件创建类名，因此可以轻松地对文件进行版本控制。如果我们将类保存在单个文件或多个文件中，它与dll的大小无关。

创建像Project＆gt;这样的文件夹结构ProductName＆gt;解决方案中的类。

Answer 2

我会为每个表类创建单独的项目吗？不，不要为每个表类创建单独的项目。那太精细了。
这会创建一个巨大的.dll吗？默认情况下，每个项目都会创建一个单独的DLL（我相信你可以使用IL merge来改变它。）但是，每个命名空间与DLL没有直接的关系。也就是说，您可以在一个DLL中拥有多个名称空间。

我们通常做的是创建一个DAL库。这将是它自己的项目，通常命名为ProductName.Data然后在其中我们可能有ProductName.Data.Models或ProductName.Data.Repositories这样的命名空间。

命名空间主要用于帮助您组织代码。他们还帮助编译器。例如，如果您有一个名为Users的数据库类，并且它位于XYZ.Data中，那么如果它位于单独的命名空间中，您仍然可以拥有一个名为Users的视图模型，例如XYZ.ViewModels。

我们所做的另一件事是在同一产品的DLL中保持根名称空间相同。所以我们最近在XYZ.Data中建立了数据库。然后我们将我们的应用程序特定逻辑放在一个单独的DLL中并命名为XYZ.AppLogic我们在命名空间XYZ.ViewModels中也有视图模型。

我不相信有任何限制你拥有的命名空间数量的硬/快规则。默认情况下，Studio将尝试为项目中的每个文件夹创建一个新的命名空间。也就是说，我经常试图避免名称空间过载，因为我不希望在我的文件顶部看到类似这样的内容：

using XYZ.Data.Models.Accounts;
using XYZ.Data.Models.Users;
using XYZ.AppLogic.Authentication;
using XYZ.AppLogic.Users;
using XYZ.AppLogic.Settings;
using XYZ.ViewModels.UserPreferences;

然而，这更像是个人偏好而不是其他任何东西。

编辑解决方案查看

MySolution
- MyProj.Data
  - 模型
    - User.cs
    - Account.cs
    - Settings.cs
- 存储库
  - UserRepository.cs
  - AccountRepository.cs

User.cs是我的POCO（Plain Ol'CLR对象），用于定义表。

Repository文件夹包含我的ORM特有的东西（我正在使用PetaPoco），这让我可以实际访问我的用户数据。

例如，我的UserRepository可能有一个方法

public User GetById(int id)
{
   var db = new Database(<myConnectionStringName>);
   return db.SingleOrDefault<User>(id);
}

该语法特定于PetaPoco，但它是我将数据对象与实际数据库连接分开的方式。

Answer 3

我正在寻找的简单答案是使用我的命名空间作为默认命名空间创建一个解决方案。对于每个文件，创建一个新类，并在每个文件中指定名称空间。感谢所有回复的人。

在命名空间下组织大量类

3 个答案: