2
我是NTiers对我的发展选择的忠实粉丝，当然它并不适合所有情况。业务层结构，你如何建立你的？
我目前正在研究一个新项目，我正在努力尝试一下我通常的工作方式，并试图查看我是否可以清理它。由于我一直是一个非常糟糕的男孩，并且在表示层中放置了太多的代码。
我的正常业务层结构是这样的（它的基本观点）：
- 业务
- 服务
- FooComponent
- FooHelpers
- FooWorkflows
- BahComponent
- BahHelpers
- BahWorkflows
- FooComponent
- 公用事业
- 常见
- 的ExceptionHandlers 个
- 进口商
- 等...
- 服务
现在上述我有很大的访问直接保存Foo对象和呸对象，通过各自的助手。
XXXHelpers让我可以访问保存，编辑和加载相应的对象，但我在哪里放置逻辑来保存具有子对象的对象。
例如：
我们有以下对象（不，我知道很好的对象）
- 员工
- EmployeeDetails
- EmployeeMembership
- EmployeeProfile
目前我w应该在表示层中构建这些代码，然后将它们传递给他们的帮助者，我认为这是错误的，我认为数据应该传递到业务层以上的某个地方并在那里进行排序。
但是我对于在哪里放置这个逻辑以及该怎么称呼这个扇区感到有点不知所措，它会作为EmployeeManager或者类似的东西下到Utilities中吗？
你会做什么？我知道这是所有的偏好。
更详细的布局
的工作流程直接包含所有的呼叫到DataRepository例如：
public ObjectNameGetById(Guid id)
{
return DataRepository.ObjectNameProvider.GetById(id);
}
然后佣工提供商进入工作流程：
public ObjectName GetById(Guid id)
{
return loadWorkflow.GetById(id);
}
这是减少重复的代码，因为您可以在工作流程中调用一次getBySomeProperty ，然后在Helper可以进行其他操作并以不同的方式返回数据，一个不好的例子是public GetByIdAsc和GetByIdDesc
通过使用DataRepository分离对数据模型的调用，这意味着可以换出另一个实例的模型（这就是思想），但ProviderHelper没有被分解，所以它不可互换，因为它不幸是EF的硬编码。 我不打算改变接入技术，但在未来可能会有更好的东西，或者只是所有酷酷的孩子现在正在使用的东西，我可能想要实现。
projectName.Core
projectName.Business
- Interfaces
- IDeleteWorkflows.cs
- ILoadWorkflows.cs
- ISaveWorkflows.cs
- IServiceHelper.cs
- IServiceViewHelper.cs
- Services
- ObjectNameComponent
- Helpers
- ObjectNameHelper.cs
- Workflows
- DeleteObjectNameWorkflow.cs
- LoadObjectNameWorkflow.cs
- SaveObjectNameWorkflow.cs
- Utilities
- Common
- SettingsManager.cs
- JavascriptManager.cs
- XmlHelper.cs
- others...
- ExceptionHandlers
- ExceptionManager.cs
- ExceptionManagerFactory.cs
- ExceptionNotifier.cs
projectName.Data
- Bases
- ObjectNameProviderBase.cs
- Helpers
- ProviderHelper.cs
- Interfaces
- IProviderBase.cs
- DataRepository.cs
projectName.Data.Model
- Database.edmx
projectName.Entities (Entities that represent the DB tables are created by EF in .Data.Model, this is for others that I may need that are not related to the database)
- Helpers
- EnumHelper.cs
projectName.Presenation
（取决于应用程序的调用是什么）
projectName.web
projectName.mvc
projectName.admin
测试项目
projectName.Business.Tests
projectName.Data.Test
那一个伟大的，我会张贴我用的是结构完整的轮廓，我只是上面显示的业务层，我也并不只是把它的业务;）很多东西你上面说的是伟大的，但对于公用事业的原因它放置XML泛型等通用类，因为它们不直接链接任何东西。无论如何，我会发布更好的结构支出，因为你已经覆盖了所有其他层次，而不仅仅是业务。 – JamesStuddart 2010-08-26 08:20:17
您的XML串行器可能属于您的数据层。例如，我有一些XML序列化的东西，负责从第三方供应商处获取数据。它生活在MyApp.Data.Repositories.Integration - 我还没有发现需要什么名字像通用“工具” – 2010-08-26 09:35:27
把你的设置管理，例如 - 对我来说，只是住在projectName.SettingsManager - 在.Utilities.Common ISN不那么直观。这当然是一个偏好问题！ :) – 2010-08-26 09:37:50