使用 LINQ to SQL 的 .NET 架构的最佳设计实践(需要 DAL?我们真的可以使用 POCO 吗?要采用的设计模式?) [英] Best design practices for .NET architecture with LINQ to SQL (DAL necessary? Can we truly use POCOs? Design pattern to adopt?)

问题描述

我一直在避免在 .net arch/n 层架构上写看起来像是另一个线程的东西，但请耐心等待.

I was avoiding writing what may seem like another thread on .net arch/n-tier architecture, but bear with me.

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

I, hopefully like others still am not 100% satisfied or clear on the best approach to take given today's trends and new emerging technologies when it comes to selecting an architecture to use for enterprise applications.

我想我正在寻求大众社区对方向和架构实施的意见您在利用当今 .NET 技术的大多数方面构建企业应用程序时会选择的方向和您将采取的方向.我最好把这个关于我和我的问题，否则会太模糊；我想改进我的架构以进行改进，并且非常想听听你们对我即将编写的技术列表的看法.

I suppose I am seeking mass community opinion on the direction and architectural implementation you would chose when building an enterprise application utilising most facets of today's .NET technology and what direction you would take. I better make this about me and my question, in fear of this being too vague otherwise; I would like to improve my architecture to improve and would really like to hear what you guys think given the list of technologies I am about to write.

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

Any and all best practices and architectural patterns you would suggest are welcome and if you have created a solution before for a similar type setup, any pitfalls or caveats you may have hit or overcome.

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

Here is a list of technologies adopted in my latest project, yep pretty much everything except WPF :)

• 智能客户端 (WinForms)
• WCF
  • 由智能客户端使用
  • 管理工具
  • 客户端工具
  • WCF 使用
  • 使用 ASP.NET MVC

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

  Utilities and additional components to consider:

  • 依赖注入 - StructureMap
  • 异常管理 - 自定义
  • 单元测试 - MBUnit

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

  I currently have this running in an n-Tier arch. adopting a Service-based design pattern utilising Request/Response (Not sure of it's formal name) and the Repository pattern, most of my structure was adopted from Rob Conery's Storefront.

  我想我或多或少对我的大多数等级感到满意(实际上只是 DAL 令我有点不安).

  I suppose I am more or less happy with most of my tiers (It's really just the DAL which I am a bit uneasy on).

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

  Before I finish, these are the real questions I have faced with my current architecture:

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

  • I have a big question mark on if I should have a custom data access layer given the use of LINQ to SQL. Should I perform LINQ to SQL directly in my service/business layer or in a DAL in a repository method? Should you create a new instance of your DB context in each repository method call (using using())? or one in the class constructor/through DI?

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

  Do you believe we can truly use POCO (plain old CLR objects) when using LINQ to SQL? I would love to see some examples as I encountered problems and it would have been particularly handy with the WCF work as I can't obviously be carrying L2S objects across the wire.

  通过在视图中保留视图逻辑、控制器调用服务/业务方法，当然还有模型中的数据访问，创建一个 ASP.NET MVC 项目本身非常清楚地显示了您应该采用的设计模式，但是对于大型项目，您是否会放弃模型"方面，尤其是在共享数据访问的情况下，您会采用什么方法来获取数据?

  Creating an ASP.NET MVC project by itself quite clearly displays the design pattern you should adopt, by keeping view logic in the view, controller calling service/business methods and of course your data access in the model, but would you drop the 'model' facet for larger projects, particularly where the data access is shared, what approach would you take to get your data?

  感谢您听取我的意见，并希望看到有关架构及其拆分方式的示例代码库.如前所述，我已经看过 Storefront，我还没有真正使用过 Oxite，但只是认为它对我自己和每个人都有好处.

  Thanks for hearing me out and would love to see sample code-bases on architectures and how it is split. As said I have seen Storefront, I am yet to really go through Oxite but just thought it would benefit myself and everyone.

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

  推荐答案

  回答您的问题:

  • 我应该直接在我的服务/业务层中执行 LINQ to SQL 还是在存储库方法中的 DAL 中执行? LINQ to SQL 仅在您的数据库映射为 1-to- 时才有意义1 与您的业务对象.在大多数企业情况下，情况并非如此，实体更合适.

  • Should I perform LINQ to SQL directly in my service/business layer or in a DAL in a repository method? LINQ to SQL specifically only makes sense if your database maps 1-to-1 with your business objects. In most enterprise situations that's not the case and Entities is more appropriate.

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

  That having been said, LINQ in general is highly appropriate to use directly in your business layer, because the LINQ provider (whether that is LINQ to SQL or something else) is your DAL. The benefit of LINQ is that it allows you to be much more flexible and expressive in your business layer than DAL.GetBusinessEntityById(id), but the close-to-the-metal code which makes both LINQ and the traditional DAL code work are encapsulated away from you, having the same positive effect.

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

  Do you believe we can truly use POCO (plain old CLR objects) when using LINQ to SQL? Without more specific info on your POCO problems regarding LINQ to SQL, it's difficult to say.

  您是否会为大型项目放弃模型"方面 MVC 模式通常比对 ASP.NET MVC 的肤浅观察所暗示的要广泛得多.根据定义，您选择用于连接到应用程序中的数据支持的任何内容都将成为您的模型.如果那是利用 WCF 或 MQ 连接到企业数据云，那就这样吧.

  would you drop the 'model' facet for larger projects The MVC pattern in general is far more broad than a superficial look at ASP.NET MVC might imply. By definition, whatever you choose to use to connect to your data backing in your application becomes your model. If that is utilizing WCF or MQ to connect to an enterprise data cloud, so be it.

  这篇关于使用 LINQ to SQL 的 .NET 架构的最佳设计实践(需要 DAL?我们真的可以使用 POCO 吗?要采用的设计模式?)的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！