使用linq-to-sql的2层（客户端 - 服务器）桌面应用程序的良好架构

Question

我们目前的架构 - UI，BusinessLayer，DAL（生成linq-to-sql）。在DAL层，我们为部分类中的实体添加了验证逻辑。 我们直接使用businesslayer中的linq-to-sql生成的实体（这是一堆类 - 类\ form）。另外，在这些bll类中，我们创建了linq-to-sql查询。

我觉得我们可以在MVP模式方面更好地分层应用程序，并拥有服务类 使用linq-to-sql提供数据。您怎么看？我应该考虑存储库模式吗？这会是一种矫枉过正吗？

Answer 1

这是一个好主意！

您的选择取决于您的申请，但这些问题很多：

1）对象数据库模型和对象模型应用程序之间的转换可能要困难得多。在这种情况下，不可能在应用程序的模型上实现过滤器，以便将生成的查询转移到SQL中。

2）通常，由于需要采样以获得连接结果（JOIN）多个表，而不仅仅是来自一个表的数据

3）并非所有SQL操作和函数在LINQ中都具有等价物

实体框架怎么样？请不要触及实体框架。这是沉重而缓慢的事情！ ：）

我更喜欢通过存储过程进行的经典数据访问和来自MS Enterprise Library的数据访问。我可以使用SQL的强大功能和我自己的业务实体的灵活性。当然 - 性能！奖牌的反面是更多的工作。我使用了一些工具来自动生成数据访问对象，然后根据需要修复它们。

运气！

Answer 2

所有好事都要考虑，但是当你开始沿着这条道路前进时，我相信你会在很多时候有更多的问题而不是答案！

当你提到Desktop和Linq-To-SQL时，我会假设你正在使用Windows Forms，这会给你带来一些实现MVP模式等方面的挑战。

虽然有针对WinForms的预先定制的MVP框架（想到MVC＃），但如果您没有开发大型应用程序，那么您可能需要轻轻地开始并使用您自己的代码实现一些概念。

Jeremy Miller的优秀Build Your Own CAB系列文章在这里是一个很好的资源，因为你可以从那里得到一些最初的几个想法，并在表格（演示文稿）和业务逻辑（演示者）之间分离一些关注点。和服务类）。

Jeremy在他的作品中主要使用了一个监督控制器设计（我喜欢），但是值得关注其他模式，例如Passive View和Model-View-ViewModel（它被融入WPF的工作方式，所以值得理解），看看你最满意的是什么。

至于你关于服务类或存储库的问题，我认为你想要的主要两级逻辑是Presenter或ViewModel实体，然后是下面的服务实体，它们可以包含你的Linq-To-SQL之类的东西查询。因此，您可能已经拥有了很多服务层的逻辑，但更多的是将其重构为一致的形式。

Answer 3

开发人员可能很难理解MVP，但你可以试一试。

Answer 4

听起来你走在正确的轨道上。如果您有一个WCF服务层，您可以在进程中或通过HTTP运行它，这意味着您可以支持客户端服务器类型的应用程序而不是从前端命中数据库，但这实际上取决于您的应用程序。