c# - 使用 LINQ to SQL 的 .NET 架构的最佳设计实践(需要 DAL？我们真的可以使用 POCO 吗？要采用的设计模式？)

Question

我一直在避免在 .net arch/n-tier 架构上编写看起来像是另一个线程的内容，但请耐心等待。

我希望像其他人一样，在选择用于企业应用程序的架构时，仍然不是 100% 满意或不清楚根据当今的趋势和新兴技术采取的最佳方法。

我想我正在就 您 在使用当今 .NET 技术的大部分方面构建企业应用程序时选择的方向和体系结构实现以及您将采取的方向征求大众社区意见。我最好就我和我的问题提出这个问题，以免这太含糊了；我想改进我的架构以改进，并且真的很想听听你们对我即将编写的技术列表的看法。

欢迎您提出任何和所有最佳实践和架构模式，如果您之前已经为类似类型的设置创建了解决方案，那么您可能遇到或克服了任何陷阱或警告。

这是我最新项目中采用的技术列表，是的，除了 WPF 几乎所有技术:)

• 智能客户端(WinForms)
• WCF
  • 由智能客户端使用
• ASP.NET MVC
  • 管理工具
  • 客户端工具
• LINQ to SQL
  • 由 WCF 使用
  • 使用 ASP.NET MVC
• 微软 SQL Server 2008

要考虑的实用程序和其他组件:

• 依赖注入(inject) - 结构图
• 异常管理 - 自定义
• 单元测试 - MBUnit

我目前在 n 层架构中运行它。采用基于服务的设计模式，利用请求/响应(不确定它的正式名称)和存储库模式，我的大部分结构是从 Rob Conery's Storefront 中采用的.

我想我或多或少对我的大部分层级感到满意(实际上只是 DAL 我有点不安)。

在我结束之前，这些是我在当前架构中面临的真正问题:

• 鉴于使用 LINQ to SQL，我是否应该拥有自定义数据访问层存在很大的问号。我应该直接在我的服务/业务层中执行 LINQ to SQL 还是在存储库方法中的 DAL 中执行？您是否应该在每个存储库方法调用(使用 using())中创建一个新的数据库上下文实例？还是类构造函数中的一个/通过 DI？

• 您认为在使用 LINQ to SQL 时我们真的可以使用 POCO(普通旧 CLR 对象)吗？我很乐意看到一些示例，因为我遇到了问题，这对 WCF 工作特别方便，因为我显然不能通过网络传输 L2S 对象。

• 自己创建一个 ASP.NET MVC 项目非常清楚地显示了您应该采用的设计模式，方法是在 View 中保留 View 逻辑，在模型中保留调用服务/业务方法的 Controller ，当然还有您的数据访问，但是对于较大的项目，尤其是在共享数据访问的情况下，您会放弃“模型”方面吗？您会采用什么方法来获取数据？

感谢您听我说完，并希望看到关于架构的示例代码库以及它是如何拆分的。如前所述，我已经看过 Storefront，但我还没有真正了解 Oxite，但只是认为它会对我自己和每个人都有好处。

在 DAL 要点中添加了附加问题。/15:42 GMT+10

Answer 1

回答您的问题:

• 我应该直接在我的服务/业务层中执行 LINQ to SQL 还是在存储库方法中的 DAL 中执行？ LINQ to SQL 只有在您的数据库一对一映射时才有意义1 与您的业务对象。在大多数企业情况下情况并非如此 Entities比较合适。

  话虽如此，LINQ 通常非常适合直接在您的业务层中使用，因为 LINQ 提供程序(无论是 LINQ to SQL 还是其他) 是您的 DAL。 LINQ 的好处在于，它允许您在业务层中比 DAL.GetBusinessEntityById(id) 更加灵活和富有表现力，但是接近金属的代码使 LINQ 和传统的 DAL 代码工作被封装远离你，具有同样的积极效果。

• 您认为在使用 LINQ to SQL 时我们真的可以使用 POCO(普通旧 CLR 对象)吗？如果没有关于 LINQ to SQL 的 POCO 问题的更多具体信息，很难说.

• 对于较大的项目，您会放弃“模型”方面吗 MVC 模式通常比 ASP.NET MVC 的表面观察可能暗示的要广泛得多。根据定义，无论您选择用于连接到应用程序中的数据支持，都将成为您的模型。如果那是利用 WCF 或 MQ 连接到企业数据云，那就这样吧。