C# 如何在相关命名空间中生成每个EF POCO类

通常我们在应用程序中有多个名称空间，例如支持、新闻、成员等
我正在使用EFV5。无法自动生成POCO类。但这些类位于同一命名空间中。
我希望在成员名称空间中有一些POCO类，在支持和。。。然后我定义了另一个分部类并扩展了生成的POCO类（添加静态方法和…。
是可能的，还是我错了。

---

注意：在这种方法中，我不想使用

新闻

类和

新闻管理器

类进行CRUD操作。

我提出了一个问题，即如何在分离关注点的情况下使用生成的POCO模型/类，我们意识到最好的方法是创建自定义模型/类，而不是直接在应用程序中使用POCO

见：

因此，您可以为自定义模型/类设置任何名称空间或特征。“坏”是：您需要将POCO数据（从EF接收）转换到您的自定义模型/类。（在上面的链接中，Tallmaris建议AutoMapper做这项工作，但我是手工做的）

---

我知道您的问题是关于在应用程序中使用POCO，但是自定义自动生成的可能会影响EF的绑定，甚至在更新EF绑定时丢失您的自定义（名称空间）。我真的不知道这是否真的很危险，但为了安全、组织和简单，我会分开做

您可以根据需要调整T4模板（

.tt

）。该文件用于生成代码。是的，但请给我完整的解决方案。如果您想为数据库中的聚合定义单独的上下文，请参阅。谢谢@Wanger，但在我看来，AutoWrapper不是RAD解决方案。AutoWrapper是SOA体系结构和DTO中的好建议。我想要的是为数据模型中的某些类（POCO生成的类）定义不同的名称空间。我想在部分POCO类中添加一些方法和计算属性，但请记住，POCO是（自动生成的）DTO，这就是为什么我告诉过你定制它并不是那么简单，这就是为什么定制它们并不容易，它们是DTO。如果您为每个POCO创建自定义类（使用自定义名称空间、方法…）（您可以自己创建，而无需AutoMapper，每个类需要5分钟）将更像是POCO的扩展，而不是架构更改。你同意我的观点吗？亲爱的Wanger，POCO是一种DTO，但具有面向对象的行为。所以在非SOA架构中，我们不需要有两个类（在非复杂场景中）。1-POCO在正确的命名空间中生成类和2-custom类（它们在大多数属性中类似）。我的重点是防止重复。