对于我的开发选择,我是NTiers的忠实粉丝,当然它并不适合每种情况。
我目前正在开展一个新项目,我正试图以我正常工作的方式玩游戏,并试图看看我是否可以清理它。因为我是一个非常坏的男孩,并且在表示层中放了太多代码。
我的正常业务层结构就是这个(基本视图):
现在有了上述内容,我可以通过各自的帮助者直接保存Foo对象和Bah对象。
XXXHelpers允许我访问保存,编辑和加载相应的对象,但是我在哪里放置逻辑来保存带有子对象的对象。
例如:
我们有以下对象(我知道不是很好的对象)
目前我会在表示层构建这些所有内容,然后将它们传递给他们的Helpers,我觉得这是错误的,我认为数据应该传递到业务层某个地方的演示文稿上面的单点并整理出来那里。
但是我对于将这个逻辑放在哪里以及在什么地方称之为扇区感到有点遗憾,它会在Utilities下面作为EmployeeManager或类似的东西吗?
你会做什么?我知道这都是首选。工作流包含直接到DataRepository的所有调用,例如:
public ObjectNameGetById(Guid id)
{
return DataRepository.ObjectNameProvider.GetById(id);
}
然后帮助者提供者访问工作流程:
public ObjectName GetById(Guid id)
{
return loadWorkflow.GetById(id);
}
这是为了减少重复的代码,因为你可以在工作流程中有一个调用getBySomeProperty 然后在Helper中进行了几次调用,可以进行其他操作并以不同的方式返回数据,一个不好的例子就是公共GetByIdAsc和GetByIdDesc
通过使用DataRepository分离对数据模型的调用,这意味着可以将模型替换为另一个实例(这是思考)但是ProviderHelper没有被分解,因此它不可互换,因为不幸的是它是EF的硬编码。 我不打算改变访问技术,但将来可能会有更好的东西,或者只是所有酷孩子现在正在使用的东西,我可能想要实现。
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.web
projectName.mvc
projectName.admin
projectName.Business.Tests
projectName.Data.Test
答案 0 :(得分:3)
答案 1 :(得分:0)
这个页面上有一个很好的图表和关于应用程序布局的描述,但是在文章的下方可以看出应用程序没有分成物理层(单独的项目) - Entity Framework POCO Repository