相关疑难解决方法(0)

我正在思考一个C#库的设计,它将有几个不同的高级函数.当然,这些高级功能将尽可能使用SOLID类设计原则来实现.因此,可能存在供消费者定期直接使用的类,以及作为那些更常见的"最终用户"类的依赖性的"支持类".

问题是,设计库的最佳方法是:

• DI不可知 - 虽然为一个或两个常见的DI库(StructureMap,Ninject等)添加基本的"支持"似乎是合理的,但我希望消费者能够将该库与任何DI框架一起使用.
• 非DI可用 - 如果库的使用者没有使用DI,那么库应该仍然尽可能容易使用,减少了用户为创建所有这些"不重要"的依赖关系而必须完成的工作量.他们想要使用的"真实"类.

我目前的想法是为常见的DI库提供一些"DI注册模块"(例如,一个StructureMap注册表,一个Ninject模块),以及一个非DI的集合或工厂类,并包含与这几个工厂的耦合.

思考？

我仍然很难绕过这个.我想像我这样分开我的图层(dll):

1)MyProject.Web.dll - MVC Web App(控制器,模型(编辑/查看),视图)
2)MyProject.Services.dll - 服务层(业务逻辑)
3)MyProject.Repositories.dll - 存储库
4)MyProject. Domain.dll - POCO类
5)MyProject.Data.dll - EF4

工作流程:

1)控制器调用服务以获取对象以填充视图/编辑模型.
2)服务调用存储库来获取/持久化对象.
3)存储库调用EF以从SQL Server获取/持久化对象.

我的存储库返回IQueryable(Of T),在其中它们使用ObjectSet(Of T).

所以我看到这一点,图层完全依赖于下一层和包含POCO类的lib？

一些问题:

1)现在我的存储库与EF一起正常工作,它们将依赖于System.Data.Objects,现在我在我的存储库层与EF紧密耦合,那是不是很糟糕？

2)我正在使用UnitOfWork模式.那住哪儿？它有一个Property Context As ObjectContext,因此它也与EF紧密耦合.坏？

3)我如何使用DI使这更容易？

我希望这是一个松散耦合的测试.有什么建议？

----------编辑----------

如果我在这里正确的轨道,请告诉我.另外,因此服务器注入一个IRepository(Of Category)权限,它如何知道它与EFRepository(Of T)的具体类之间的区别？与UnitOfWork和服务相同？

一旦有人帮助我把它弄清楚到我所理解的地方,我知道它看起来似乎微不足道,但是男人,我有一个时间包围我的头!

调节器

Public Class CategoryController
    Private _Service As Domain.Interfaces.IService

    Public Sub New(ByVal Service As Domain.Interfaces.IService)
        _Service = Service

    End Sub

    Function ListCategories() As ActionResult
        Dim Model As New CategoryViewModel

        Using UOW As New Repositories.EFUnitOfWork
            Mapper.Map(Of Category, CategoryViewModel)(_Service.GetCategories)
        End Using

        Return …