我们正在使用 Visual Studio 2010 将 Windows 应用程序转换为基于 .Net 的浏览器。虽然我对 .Net 并不陌生，但我对创建基于 3 层架构的应用程序很陌生。我想为我们数据库中的每个表创建类并将它们放在命名空间下。类名将与表名相同，因此命名空间中的每个类都将被引用，例如 CompanyName.ProductName.Entity.{table name}。现在回答我的问题：
这可行吗？
我会为每个表类创建单独的项目吗？请注意，随着更多程序的转换，将创建新的表类。
这会创建一个巨大的 .dll 吗？
其他开发人员如何访问我创建的类，它们存储在哪里以便我可以使用 Using 指令引用这些类？
【问题讨论】：
标签： namespaces
始终使用单独的 cs 文件创建类名，因此很容易对文件进行版本控制。如果我们将类保存在单个文件或多个文件中，它与 dll 的大小无关。
在您的解决方案中创建像 Project > ProductName > Classes 这样的文件夹结构。
【讨论】：
我们通常所做的是创建一个 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;
不过，这更多的是个人喜好。
编辑解决方案视图
User.cs 是我定义表的 POCO（Plain Ol' CLR Object）。
Repository 文件夹包含特定于我的 ORM（我正在使用 PetaPoco）的东西，这让我可以实际访问我的用户数据。
例如，我的 UserRepository 可能有一个方法
public User GetById(int id)
{
var db = new Database(<myConnectionStringName>);
return db.SingleOrDefault<User>(id);
}
该语法特定于 PetaPoco，但它是我将数据对象与实际数据库连接分开的方式。
【讨论】：
我一直在寻找的简单答案是使用我的命名空间作为默认命名空间创建一个解决方案。对于每个文件，创建一个新类，并在每个文件中指定名称空间。感谢所有回复的人。
【讨论】：