1

我还在为 OOP 概念和依赖注入而苦苦挣扎，所以请耐心等待。

我已经使用 User 表生成了我的 Linq2Sql 模型，现在我希望能够向该用户发送确认电子邮件，因此我为我的 User 对象创建了一个部分类文件，我觉得添加一个 SendConfirmationEmail() 方法是很自然的到用户类。此方法将使用 MailService 发送实际的电子邮件，我想使用依赖注入来传递服务，所以我在 User 对象上创建了一个构造函数重载，如下所示

public User(IMailService service) : this()
{
    _service = service;
}

SendConfirmationEmail 方法看起来像这样

public void SendConfirmationEmail()
{
    _service.SendMail(params...);
}

我意识到这是一种糟糕的依赖注入，我希望稍后切换到依赖注入框架，因为我对此有了更多的了解。

对我来说，问题是我需要从我的模型 dll 到我的服务 dll 的引用，这看起来不正确，因为我不确定我的 linq2sql 生成的实体与依赖注入框架和 OOP 概念的关系如何（我认为 ninject 看起来最有希望）。

我希望比我有更多经验的人能告诉我我是否朝着正确的方向前进。我知道我可以让它发挥作用，但我想教育自己在同一步骤中以正确的方式做到这一点。

4

3 回答 3

2

我个人会更改您架构中的一些内容：

  • 我不认为 SendConfirmationEmail 应该是您的 User 对象的方法。但应该是另一个以用户为参数的对象上的方法。（这也更好地将您的 Dal 与其他逻辑分开。

  • 第二个在这个方法中使用这样的东西：

    Services.Get<IMailService>().SendMail(params ...);

您可以将服务实现为 folowin（只是一个示例）：

public class Services
{
    protected static Dictionary<Type, object> services = new Dictionary<Type, object>();

    private Services() 
    {
    }

    static Services()
    {
        // hard coded implementations...
        services.Add(typeof(IMailService), new DefaultMailServiceImplementation());
    }

    public static T Get<T>() where T : class
    {
        Type requestedType = typeof(T);
        return services[requestedType] as T;
    }
}

通过使用“服务”类（或您喜欢的名称），您可以在 IOC 框架和您的代码之间添加一个额外的层，这使得更改 IOC 框架变得容易。只需将 Get 方法中的实现更改为使用一个。您还可以在静态构造函数中使用硬编码的临时解决方案（直到您使用 IOC 框架）（就像我在上面的示例中所做的那样）。

于 2009-01-05T13:56:31.140 回答
1

这种方法的问题是实体大部分时间来自 LINQ-to-SQL 后端，因此不会使用您的构造函数（LINQ-to-SQL 以自己的方式创建对象; 您不能强制 LINQ-to-SQL 使用您的构造函数） - 所以这只对您自己创建的（少数）对象有用。默认情况下，数据绑定（等）通常也会使用无参数构造函数。

我想知道这作为接受服务或通过工厂/单例获取服务本身的实用方法是否不会更好。

于 2009-01-05T12:56:58.920 回答
1

我认为你可以这样做，但你可能想做两件事来保护自己免受未来的跨层依赖问题：

  1. 为您的用户对象创建一个接口。您应该这样做，因为不这样做将意味着使用此业务对象的所有内容都必须引用 LINQ dll。
  2. 将依赖注入从构造函数移到属性中。您这样做是因为构造函数注入往往会限制您动态创建对象的能力。这样做虽然会带来问题，因为您必须为_service. 您可以通过创建 IMailService 的“空”实现并将其设置为 _service 的默认值来解决此问题。
于 2009-01-05T13:53:10.617 回答