问题列表 - 第6813页 | 那些遇到过的问题

但是,我有一个关于如何为我的应用程序所包含的对象设计实体基类的问题.我有一个简单的类库,Web应用程序是建立在它之上的.该库公开了一个IRepository接口,默认实现(应用程序使用的接口)使用了Linq-to-SQL(DataContext等没有公开给Web应用程序),只是包含获取这些实体的方法.存储库基本上看起来像这样(简化):

public interface IRepository
{
    IEnumerable<T> FindAll<T>() where T : Entity
    T Get<T>(int id) where T : Entity
}

Run Code Online (Sandbox Code Playgroud)

默认实现使用DataContext上的GetTable()方法来提供正确的数据.

但是,这要求基类"Entity"具有一些功能.通过创建一个与Linq-to-SQL给我的映射对象同名的部分类,很容易让我的对象继承它,但是这样做的"正确"方法是什么？

例如,上面的接口具有通过它的id获取实体的功能 - 从实体派生的所有不同类的类确实具有int类型的"id"字段(从它们各自的表的主键映射),但是我如何以一种允许我像这样实现IRepository的方式来指定它呢？

public class ConcreteRepository : IRepository
{
    private SomeDataContext db = new SomeDataContext();

    public IEnumerable<T> FindAll<T>() where T : Entity
    {
        return db.GetTable<T>().ToList();
    }

    public T Get(int id) where T : Entity
    {
        return db.GetTable<T>().Where(ent => ent.id == id).FirstOrDefault();
    }
}

Run Code Online (Sandbox Code Playgroud)

我在无编译器的PC上从内存中执行此操作,因此原谅任何错误,您希望得到我的意图.

这里的诀窍当然是为了编译它,必须确定Entity承诺从它派生的每个人都有一个id字段.

我可以创建一个抽象字段,或者由Linq-to-SQL粘贴在生成的类中的id字段"隐藏"的普通字段.

但这一切都像是作弊,甚至给编译器警告.

应该"实体"真的是"IEntity"(而不是接口),我应该尝试以Linq-to-SQL将实现的方式定义id字段？这也可以很容易地指定实体实现者需要实现的其他接口.

或者"实体"应该是一个带有抽象id字段的抽象基类,它是否应该以抽象方式实现所需的接口以供其他人覆盖？

我不太清楚C#是否能够找到优雅的解决方案,所以我很乐意听到更有经验的系统设计师的一些基础经验.

谢谢!

编辑4月10日:

我看到我在这里遗漏了一些重要的东西.我的IRepository有两个具体的实现 - 一个是使用LINQ to …

c# oop linq-to-sql

Run*_*sen

2009 05-02

6
推荐指数

1
解决办法

8686
查看次数

在C#中实现生产者/消费者模式

如何使用事件和代理在C#中实现Producer/Consumer模式？在使用这些设计模式时,我需要注意什么？我需要注意哪些边缘情况？

.net c# events design-patterns producer-consumer

tus*_*h1r

2018 06-06

13
推荐指数

1
解决办法

2万
查看次数

你是如何与敏捷项目签订合同的？(不是你怎么想的,你是怎么做的)

要执行敏捷项目,首先需要一份合同.没有合同 - 没有项目!没有项目 - 没有敏捷,SCRUM或任何东西!

如果我们谈论大中型项目,合同必须有明确的安全触发器.即客户希望非常肯定,如果我们同意在时间上结束项目= T,预算= B和范围= S,我们最终不会以时间= T×2,预算= B×3或范围= S/2.

另一方面,作为提供产品的公司,我们不希望项目意外结束.即如果经过一番迭代,客户说"现在我发现这实际上就是我们所需要的.我们现在停下来." 这个项目计划再过2个月,而不是没有计划工作的人.如果3-6人不是一个大问题,15-25可能是一个真正的问题!

然而,我没有找到任何具有安全功能的合同的真实示例,这将允许项目以完全敏捷的方式执行(声明或未向客户声明).我在许多论坛上找到的标准说法 - 与客户交谈,向他解释这是一种更有成效的工作方式等,并不能说服我和我的管理层.并不是说我们不相信敏捷实际上是一种更好的方式.只是安全触发器中的差距是如此明显,以至于我们的客户都没有买它而且我们不喜欢它们(差距,而不是客户;)).

请不要"它可能会以这种方式工作......" - 我已经阅读了大量的内容.只对"为我们这样工作"感兴趣.毫无疑问,跳过所有自信的信息.

PS据我所知,标准迭代,特征驱动的方法建议客户在每次迭代(迭代次数)后付款,并且能够在任何迭代之后由客户和项目执行者停止项目而不会过多地说明后果,而不是说"无论如何都会失败,所以越早越好"(这是正确的,但在签订合同时并不是很有帮助).

agile project-management scrum

Dan*_*kas

2012 02-19

35
推荐指数

3
解决办法

2531
查看次数