LINQ to SQL体系结构.什么是最好的？

Question

这个问题就像一个游泳池.我们正在尝试使用LINQ to SQL等ORM来确定最佳结构.我们定义的归档是用于其他应用程序将通过直接引用DLL或通过Web服务访问的一种框架.我们有.NET应用程序和PHP应用程序.

可能性是:

多个数据上下文:将数据库分成工作单元,并为每个工作单元创建单独的上下文.

优点:

• 易于使用
• 类将被分解为不同的命名空间
• 维护较小的域

缺点:

• 如果相关,则必须复制对象,从而创建维护地狱
• 对象不能在上下文之间传递,因此需要在数据库上进行另一次命中

单一数据上下文:所有表,视图,过程都位于同一个巨大的上下文中.

优点:

• 没有重复
• 关系很容易管理,基本上LINQ负责处理它.
• 更好的性能,更少的数据库命中率.

缺点:

• 所有表都在相同的命名空间中,代码完成变得疯狂
• 对设计师来说不是最好的(至少在VS2008上)
• 不能选择保存什么,不保存什么.全部保存,或删除所有模式.

嗯,这是我想到的事情,所以如果有任何其他优点或缺点,请告诉我,我会将它们包括在帖子中.也选择你最好的一个.

谢谢大家

Answer 1

我理解你的疑虑.当我开始使用LinqToSql时,我也有同样的想法.为了帮助我找到更好的方法,我开始创建一个个人项目,在那里我可以毫无顾虑地毫无先决后地测试所有方法.

在这个练习中,我发现唯一一种上下文方法是最有用的.此解决方案似乎更易于维护,如果您需要重新创建域,您将只管理一个项目中的一个文件.

我在练习中意识到的其他方面是直接使用LinqToSql在组织方面效率不高.如果你有一个项目,团队将执行开发而不是只有一个人,你应该"屏蔽"LinqToSql.应该有一个"治安官"来处理域名,你也应该使用一些抽象机制来保护模型不被滥用(我实现了一个Repository模式,它运行良好,但你可以找到不同的方法).

我还遇到了在域内创建一些逻辑组的问题.我真正做的就是使用一些DDD(领域驱动设计)技术来创建所谓的聚合.聚合是域内实体的逻辑排列,其中您具有根实体(用作聚合器)以及它们之间相关的其他几个卫星实体.您可以在LinqToSql域中创建一些新实体.这些新实体将与数据库断开连接,并将作为聚合器.这种方法可以让您在域内创建"子域",并帮助您获得更好的设计.

最后我意识到使用LinqToSql的最佳方法是将上下文视为简单的DAL.重用其域,带有一些扩展(我们可以使用T4来帮助我们创建代码),其中实体被转换为DTO(数据传输对象)以将数据暴露给其他层.

我正在发布(它还没有完成)我在博客中练习的步骤:http://developmentnirvana.blogspot.com/