问题标签 [poco]

我对另一个 SO 线程的这个答案很感兴趣，我希望有人可以帮助我阐明这个概念。

假设我有一个主 AppDomain 和一堆由主 AppDomain 创建和初始化的子 AppDomain。在伪代码中：

主要应用程序域：

子应用域：

在 Init() 期间，子 AppDomain 实例化一个 POCO 对象，根据定义，该对象是不可编组的。我们还假设我们不能在这方面修改它。

链接的答案表明，将它包装在一个Container<T>（它本身是可编组的）中应该允许它被传递回主 AppDomain。我理解这一点，因为它Container<MyInfo>是真正被传递的实例的代理。

我不明白的是主 AppDomain 怎么可能通过容器的代理访问容器中的 POCO 实例。我看到了重载的隐式转换运算符Container<T>，我知道它返回包含的 POCO 实例。但是该实例本身并没有被代理 - 它仍然在子 AppDomain 中！那么，这不应该中断吗？

这里到底发生了什么？

我正在开发一个需要通过 FTP 进行交互的应用程序。对于这种交流，我目前在 Windows 上使用 C++、Visual Studio 和 Poco。

以下行导致 bad_alloc 异常...

所以我下去尝试先初始化一个StreamSocket，也失败了......

当走得更远时，bad_alloc 似乎来自：

该构造函数包含：（我在调试器中看到 _pImpl 未初始化）

IPv4AddressImpl::parse 包含：

以下带有来自 Winsock2.h (ws2_32.lib) 的 inet_addr 的代码会导致“SOMETHING ELSE”。

我看不出这里出了什么问题......有没有办法进一步调试这个问题或者有人知道出了什么问题？

通常需要在 UI 上以各种方式显示域对象；列表、搜索结果、查看和编辑页面，以及页眉、页脚和弹出窗口。通常，您有几个不同的域对象“视图”，每个视图都显示不同的字段。

大多数建议似乎是在需要子集或超集时使用 DTO 获取数据。维护 DTO 有很多开销。简单地填充每个场景所需的域对象的属性是一种不好的方法吗？例如，您可以使用配置文件来说明应该包含哪些属性，例如：

service.GetDomainObjects(int listID, Profile.ListProfile); service.GetDomainObjects(string searchParam, Profile.SearchProfile);

我正在查看POCO 和 DTO 之间的区别（看起来 POCO 是具有行为（方法？）的 dto），并遇到了 Martin Fowler 关于贫血域模型的这篇文章。

由于缺乏理解，我想我已经创建了这些贫血的领域模型之一。

在我的一个应用程序中，我在“dto”dll 中定义了我的业务域实体。它们有很多与 getter 和 setter 相关的属性，其他的不多。我的业务逻辑代码（填充、计算）在另一个“bll”dll 中，而我的数据访问代码在一个“dal”dll 中。“最佳实践”我想。

所以通常我会像这样创建一个 dto：

并将其传递给 bll 层，如下所示：

反过来，它执行一些逻辑并将其传递给 dal 层，如下所示：

据我了解，要使我的 dto 成为 POCO，我需要使业务逻辑和行为（方法）成为对象的一部分。因此，而不是上面的代码，它更像是：

IE。我在对象上调用方法，而不是将对象传递给方法。

我的问题是 - 我怎样才能做到这一点，并且仍然保留关注点的“最佳实践”分层（单独的 dll 等......）。在对象上调用方法不就意味着必须在对象中定义方法吗？

请帮助我的困惑。

阅读有关实体框架中缺乏持久性无知的信息时，我经常偶然发现POCO Adapter。问题是，有没有人在生产中使用它，它是如何进行的，有什么陷阱？

我考虑了应用程序设计的两种选择：在业务逻辑中使用带有该适配器的 POCO，并让表示层使用它们或创建在 EF 实体和 DTO 之间转换的服务层：(1) EF 实体 <-> 适配器 <-> POCO 业务对象 <-> 表示或 (2) EF 实体 <-> 服务层 <-> DTO <-> 表示。第一种方法似乎更干净，但我有点犹豫 POCO Adapter 不是非常标准的解决方案，并且可能包含一些目前不明显的缺点。

我看过很多关于 POCO 的文章。这是什么？

我希望我的单元测试涵盖我的 POCO。

我应该如何测试它们？

如果我添加一个新属性怎么办？如何让我的测试失败？

测试我知道的属性和方法，但问题是，如何确保我的测试失败是将任何东西添加到我的 poco 中。

我的团队有一些关于更新实体数据以及如何最好地处理它的讨论。这是一个安全框架，所以这里有一些限制和想法。

1. DB 中的每个表都有一个作为 guid 的 PK，这是我们的多节点集群解决方案所必需的。我们的想法是我们不想通过 API 将实体上的这个暴露给客户，因为它可以做两件事，
   1. 为他们提供工作所需的更多信息，并为黑客提供有关系统的更多信息。
   2. 支持噩梦是客户端以某种方式硬编码到此 ID，如果我们需要更改 PK 的客户端会受到影响。

解决方案是公开项目的自然键，例如具有唯一名称的角色对象和领域，一起保证唯一性但是更新这些值中的任何一个都是挑战，因为您需要指定要更新的旧值和新值，或者传递两个原始对象和新对象中的对象，因此我们可以找到要更新的对象。有点乱，

另一种方法是制作一个备用密钥并将其公开给客户，他们可以随心所欲地使用它，我们不在乎，因为它与我们的 PK 无关。

现在似乎每个人都只是使用 PK 作为实体的 ID，没有任何问题，不知道如何说服我们的老兵团队从过去的编程时代开始。

另一个问题是如何支持部分更新，问题是您拥有具有 10 个属性、4 个集合等的实体......具有名称+领域组合并指定要更新的属性而不是下拉整个对象更改 1 字段，发回更新。我说延迟加载集合，但不确定部分更新是否有意义。

想法？

谢谢！

我有三个表项目、用户和项目成员。ProjectMembers 表是一个映射表，只有两列 ProjectId 和 UserId。

在我的对象模型中，我有两个类 Project 和 User。Project 类有一个属性IEnumerable<User> Members

我正在使用外部 xml 映射文件将 linq 映射到 sql 关联。我能够获取项目和用户数据，但我不知道如何映射成员关联。

假设您有三层（带有命名空间）：

• 用户界面 ( App.UI) - 调用业务层流程并使用对象进行通信
• 业务层 ( App.Core) - 使用对象编排流程并使用 DAL 层
• DAL ( App.Data) - 直接操作存储和持久化对象

假设您有 User 表，因此反映在您的 DAL 层中，App.Data.User并且可能也反映在App.Data.Users.

您的 UI 中有一个显示应用程序用户的视图。

要真正拥有一个分离（分层）的应用程序，您还应该拥有App.Core.User并且App.Core.Users可能必须手动创建。

最好的解决方案（在我看来）当然是：应该有第四层业务对象（App.Objects），其中包含类App.Objects.User和App.Objects.Users. 这些 POCO 将在所有层之间共享。业务层只允许使用 DAL，UI 只允许使用 BL，但它们都将App.Objects用于公共对象模型。

Asp.net MVC 模板暗示直接在视图上使用 DAL 对象，LINQ 2 实体本身也不创建任何 POCO...

那么当使用任何自动代码生成时，我们应该使用 DAL 对象还是手动硬编码我们共享的 POCO？第一部分似乎是一个简单的出路，但没有将 DAL 与 UI 分开（以后可能会有安全性和可伸缩性问题），第二部分容易出错并且对于中等大小的数据库非常乏味。

你有什么建议？