3

在我破坏我的应用程序之前，我当前的命名空间看起来像这样：

CompanyAbc.Core
CompanyAbc.AppXyz.Web
CompanyAbc.AppXyz.Business

CompanyAbc.Core 命名空间包含我们公司所有应用程序使用的通用代码。一个例子是一个名为“ClientMessage”的类，我们用它作为容器将消息从一层传送到另一层（例如，在将数据保存到数据层时，抽象出来并支持显示成功或错误消息。 UI层）

我们现在将 CompanyAbc.AppXyz.Business 制作成 WCF 服务。我的问题是：“共享”（或不共享）这些基本/通用实体的最佳做法是什么？

例如，您是否会：

a) 将 [DataContract] 属性直接添加到 CompanyAbc.Core 命名空间中的类，即使它与 WCF 无关。

   CompanyAbc.Core.Entities
            ClientMessage.cs

或者

b) 创建一个与 CompanyAbc.Core 命名空间完全相同的数据传输对象？

   CompanyAbc.Core.Entities
            ClientMessage.cs
   CompanyAbc.AppXyz.Business.DataContracts
            ClientMessageDto.cs

或者

c) 其他选择？

另一个复杂性是我们打算共享这些程序集。但是为了强制解耦而不共享程序集/业务实体，你会全力以赴做这样的事情吗？

   CompanyAbc.Core
   CompanyAbc.Core.Shared.Entities
      ClientMessage.cs

   CompanyAbc.AppXyz.Web
   CompanyAbc.AppXyz.Web.Entities
      ClientMessage.cs --> derives from the Core.Shared, or just duplicate code?

   CompanyAbc.AppXyz.Business.Entities
      ClientMessage.cs --> derives from the Core.Shared, or just duplicate code?
   CompanyAbc.AppXyz.Business.DataContracts
      ClientMessageDto.cs
4

2 回答 2

1

我建议您在程序集中创建“层次结构组”，以使其更简洁且使用更直观。例如：（以@learner 示例为基础）

ABC.Common (It communicates better the intention)
ABC.Core
ABC.Core.Web
ABC.Core.Windows
ABC.Services.DataContracts
ABC.Services.ServicesContracts

等等 ...

建立一个清晰的层次结构会刺激开发人员使用它，因为它适合之前已经部署的程序集。查看 .NET 程序集以供参考。

于 2014-11-29T00:42:19.320 回答
0

这是我的命名空间的样子，因为我到目前为止使用它：

ABC.Core
ABC.Data
ABC.Business
ABC.Web;
ABC.Services (common)
ABC.Services.DTO (common)
    ABC.Services.Svc1
        ABC.Services.Svc1.DTO
    ABC.Services.Svc2
        ABC.Services.Svc2.DTO

在实践中，您不希望在服务之间有这么多共享类，因为它们可能希望彼此分开。彼此独立越好，您可以更好地对它们进行版本控制，但确实需要在每个服务的 DTO 级别中使用一些重复的代码。许多人使用 Automapper 将 Core 类投影到 DTO 中。

让我知道你的想法。

于 2012-07-26T21:11:26.913 回答