我们目前的架构 - UI、BusinessLayer、DAL（生成的 linq-to-sql）。在 DAL 层中，我们为部分类中的实体添加了验证逻辑。 我们在businesslayer中直接使用linq-to-sql生成的实体（这是一堆类-class\form）。此外，在这些bll类中，我们创建了linq-to-sql查询。
我觉得我们可以根据 MVP 模式更好地对应用程序进行分层，并拥有服务类 它使用 linq-to-sql 提供数据。你怎么看？我应该考虑存储库模式吗？会不会有点矫枉过正？
【问题讨论】：
这是个好主意！
您的选择取决于您的应用程序，但有很多问题：
1) 对象数据库模型和对象模型应用程序之间的转换可能要困难得多。在这种情况下，不可能在应用程序的模型上实现过滤器，以便将生成的查询传输到 SQL 中。
2) 通常，由于采样需要获得连接（JOIN）多个表的结果，而不仅仅是来自一个表的数据
3) 并非所有 SQL 操作和函数在 LINQ 中都有其等效项
实体框架呢？请不要碰实体框架。这是沉重而缓慢的事情！ :)
我更喜欢通过存储过程和来自 MS 企业库的数据访问的经典数据访问。我可以使用我自己的业务实体的强大功能和灵活性。当然 - 性能！奖牌的反面是更多的工作。我使用了一些工具来自动生成数据访问对象，然后根据需要修复它们。
好运！
【讨论】：
所有好事情都值得考虑，但是当你开始走这条路时，我相信你很多时候会遇到比答案更多的问题！
当您提到桌面和 Linq-To-SQL 时，我假设您使用的是 Windows 窗体，这会给您在实现诸如 MVP 模式之类的东西时带来一些挑战。
虽然有针对 WinForms 预先定制的 MVP 框架（想到 MVC#），但如果您不是在开发大型应用程序，那么您可能希望从温和的开始并使用您自己的代码实现一些概念。
Jeremy Miller 出色的Build Your Own CAB 系列文章是这里的一个很好的资源，因为您可以从中提取一些最初的想法，并在表单（演示）和业务逻辑（演示者和服务）之间进行一些关注点分离类）。
Jeremy 在他的工作中主要使用了监督控制器设计（我喜欢），但它值得研究其他模式，例如 Passive View 和 Model-View-ViewModel （已融入 WPF 工作方式，因此值得了解)，看看你觉得什么最舒服。
至于您关于服务类或存储库的问题，我认为您想要的主要两个逻辑级别是 Presenter 或 ViewModel 实体，然后是下面的服务实体，可以包含您的 Linq-To-SQL 之类的东西查询。因此，您的服务层可能已经有很多逻辑，但更多的是将其重构为一致的形式。
【讨论】：
听起来你是在正确的轨道上。如果您有 WCF 服务层，您可以在进程中或通过 HTTP 运行它，这意味着您可以支持客户端服务器类型的应用程序，而不是从前端访问数据库，但这实际上取决于您的应用程序。
【讨论】：
MVP 对开发人员来说可能很难理解，但您可以试一试。
【讨论】：