我正在重新设计我的项目，旨在使其更易于维护，并尽最大努力遵循良好的设计实践。目前，我的解决方案包括一个Silverlight组件，用于托管SL应用程序的ASP.Net主机，还包含一个WCF RIA服务，以及一个共享类库，这样SL和WCF服务就可以共享对象。业务逻辑分散在各个地方，在我的WCF服务中手动编写所有CRUD操作。因此，我正在为所有内容创建一个新结构，并将这个混乱的结构移植到新格式中。在此过程中，我发现当我不知道是否应该这样做时，我正在复制类。
我的新结构如下：
客户端：
Reporting.Silverlight = Silverlight应用程序。这将引用我的DTO类。
Reporting.Web = 包含我的SL应用程序，是人们进入应用程序的主要入口点。
业务：
Reporting.Services = 我的WCF服务位于此处。我的SL应用程序将调用此处的服务进行操作，而这些服务将返回DTO类。
Reporting.Services.Contracts = 包含我的WCF服务接口，并包含带有DataContract装饰器的DTO类。
Reporting.Domain = 包含我的领域对象和业务逻辑。
数据：
Reporting.Data.Contract = 包含我的存储库和工作单元接口。
Reporting.Data = 存储库/工作单元的具体实现。在此定义Entity Framework 5上下文。
Reporting.Data.Models = 包含所有我的实体对象，以便EF5可以使用SQL操作。
我有3个地方几乎具有完全相同的类，对我来说这很可疑。在Reporting.Services.Contracts中，我有一个DTO被传递给SL客户端。以下是其中一个示例：
[DataContract(Name = "ComputerDTO")]
public class ComputerDTO
{
[DataMember(Name = "Hostname")]
public string Hostname { get; set; }
[DataMember(Name = "ServiceTag")]
public string ServiceTag { get; set; }
// ... lots more
}
我认为上面的DTO很好，因为它只是一组传递给SL客户端的属性。我的大部分DTO属性都与实体对象的属性1:1映射，除了ID字段。以下是与上述DTO对应的实体对象：
[Table("Inventory_Base")]
public class ComputerEntity
{
// primary key
[Key]
public int AssetID { get; set; }
// foreign keys
public int? ClientID { get; set; }
// these props are fine without custom mapping
public string Hostname { get; set; }
public string ServiceTag { get; set; }
// ... plus a bunch more in addition to my navigation properties
}
我正在使用EF5的代码优先方法。 我仍处于重新编写的初始阶段，到目前为止，我的印象是业务逻辑不应该在EF实体内部。 DTO也不应该有业务逻辑。 那么这意味着它应该放进我的领域模型中，对吗？好吧，那就在Reporting.Domain中再创建一个几乎相同的第三个类。
public class Computer
{
public string Hostname { get; set; }
public string ServiceTag { get; set; }
// ... lots more, pretty much mirrors the DTO
public string Method1(string param1)
{
// lots of methods and logic go in here
}
}
如果有助于更好地定义我正在尝试做什么，请让我知道我正在遵循的存储库/单元工作方法论。