在没有了解所有血腥细节的情况下,我正在尝试设计一个基于服务的解决方案,该解决方案将被多个客户端应用程序使用。该解决方案允许管理员创建和修改常规用户用于执行数据输入的文档模板。我的目的是使应用程序成为最佳实践,技术等的学习工具。
而且,与此同时,我必须适应精神分裂症的环境,因为“有权力”不能坚持他们关于技术和工具的决定。例如,我今天使用的是Linq-to-SQL,因为他们还没有准备好去EF4,但也有关于切换到NHibernate的讨论。因此,我必须尽可能地使代码保持无知,以便在我们更改OR / M工具时最大限度地减少工作。
此时,我还限制使用部分类方法来扩展Linq-to-SQL类,以便它们实现在业务层中定义的接口。我不能使用POCO,因为管理层坚持我们利用所有内置工具等,所以我必须支持Linq-to-SQL设计师。
也就是说,我的服务接口有一个StartSession方法,在其签名中接受模板标识符。操作流程如下:
我的第一个目标是在我的应用程序的逻辑层之间创建干净的分离。第二是保持持久性无知(如上所述)。第三,我必须能够测试所有内容,因此必须将所有依赖项外部化以便于模拟。我使用Unity作为IoC工具来帮助这个领域。
为实现这一目标,我已根据需要定义了服务类和数据协定以支持服务接口。服务类将从实际执行工作的业务层注入依赖项。而这里对我来说已经变得混乱了。
我一直试图通过工作单元和存储库路线来帮助坚持无知。我有一个ITemplateRepository和一个ISessionRepository,我可以从我的IUnitOfWork实现中访问它。服务类获取我注入的SessionManager类(在我的BLL中)的实例。 SessionManager通过构造函数注入接收IUnitOfWork实现,并将所有持久性委托给UoW,但我发现自己正在玩各种逻辑的shell游戏。
上述所有逻辑都应该在SessionManager类中,还是在UoW实现中?我希望在存储库实现中尽可能少的逻辑,因为更改数据访问平台可能会导致对应用程序逻辑的不必要的更改。由于我的存储库正在针对接口工作,我如何才能最好地创建新会话(请记住,有效会话具有对模板的引用,呃,正在使用的表单)?尽管我必须支持设计人员并在存储库实现中使用AutoMapper之类的工具来处理对象的翻译,但是仍然使用POCO会更好吗?
唉!
我知道我只是陷入分析瘫痪,所以我可能需要一点点轻推。如果有人可以提供一个示例,如果有我已定义的业务规则和架构限制,您将如何解决问题,那将是理想的。
答案 0 :(得分:0)
如果你不使用POCO,那么你真的不会与数据存储无关。使用POCO将允许您使用基于内存的存储库启动和运行系统,这是您可能希望用于单元测试的任何方式。
AutoMapper听起来不错,但我不认为这是一个交易破坏者。将POCO映射到EF4,LinqToSql,nHibernate并不是那么耗时,除非你有数百个表。当/如果您的POCO开始偏离持久层时,您可能会发现AutoMapper不适合该账单。