使用 Linq-to-Sql 接口进行解耦

发布于 2024-08-03 20:36:01 字数 380 浏览 6 评论 0原文

我正在将模型类重构为接口。模型类是使用 Linq-to-Sql 自动生成的。

class FooRepository 
{
    // ...
    public void Add(IFoo foo) 
    {
        db.Foos.InsertOnSubmit(foo);    
    }
}

InsertOnSubmit 方法采用 Foo 的实例，而不是 IFoo。我可以将实例内联转换为 (Foo) 并且这可以工作，但是有没有更干净的方法来做到这一点？

我已经在使用 StructureMap，我可以向 Add 方法添加一个属性来根据我的映射解析类型吗？

或者我可以重写任何模型类方法，或使用部分事件来完成此任务吗？

原文

I am re-factoring a model class into an interface. The model class is auto-generated with Linq-to-Sql.

class FooRepository 
{
    // ...
    public void Add(IFoo foo) 
    {
        db.Foos.InsertOnSubmit(foo);    
    }
}

The InsertOnSubmit method takes an instance of Foo, not an IFoo. I can cast the instance inline to (Foo) and this works, but is there a cleaner way to do this?

I am already using StructureMap, can I add an attribute to the Add method to resolve the type based on my mappings?

Or can I override any of the model classes methods, or use the partial events to accomplish this?

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

辞别 2024-08-10 20:36:01

为了将 DLINQ 模型与控制器分开，我倾向于不传递 LINQ 模型，而是使用控制器使用的不同模型，该模型在调用 DLINQ 方法之前传递到我的类中。

这样，即使数据库中可能有许多其他可用属性，我也可以在控制器中仅包含应用程序所需的属性。

这样，如果数据库结构发生变化，则只需更改 DAO 类（例如 FooRepository），其他所有内容都不会受到连锁反应。

我不知道您是否愿意做这样的事情，但这将是一个比使用我期望的接口更简单的设计。

回复收藏 0 原文

盗心人 2024-08-10 20:36:01

不知道这是否适合，但也许使用泛型可能是一个主意？

class FooRepository<T>
where T: class, IFoo, new() 
{
    // ...
    public void Add(T foo) 
    {
        db.Foos.InsertOnSubmit(foo);    
    }
}

你可以做这样的事情 -

Foo bar = new Foo();
FooRepository<Foo> foo = new FooRepository<Foo>();
bar.Add(bar);

或者这样...

Bar bar = new Bar(); //Bar implements IFoo
FooRepository<Bar> foo = new FooRepository<Bar>();
bar.Add(bar);

这样，FooRepository 中的 T 实际上是一个 Foo （或一个 Bar），而不是一个 IFoo，所以不需要强制转换，但是 where 子句中的限制意味着它必须实现 IFoo，这是 Foo（和 Bar）所做的。

Dunno if this will suit, but perhaps using genrics might be an idea?

class FooRepository<T>
where T: class, IFoo, new() 
{
    // ...
    public void Add(T foo) 
    {
        db.Foos.InsertOnSubmit(foo);    
    }
}

And you can do something like this -

Foo bar = new Foo();
FooRepository<Foo> foo = new FooRepository<Foo>();
bar.Add(bar);

Or this...

Bar bar = new Bar(); //Bar implements IFoo
FooRepository<Bar> foo = new FooRepository<Bar>();
bar.Add(bar);

That way, T in FooRepository is actually a Foo (or a Bar), not an IFoo, so no casting is required, but the restriction in the where clause means that it must implement IFoo, which Foo (and Bar) does.

回复收藏 0 原文

~没有更多了~