使用LINQ to SQL的.NET体系结构的最佳设计实践（DAL是否必要？我们能否真正使用POCO？采用设计模式？）
我正避免在.net arch / n-tier体系结构上编写看起来像另一个线程的东西，但请耐心等待。
在选择用于企业应用程序的体系结构时，我希望与其他人一样，对于采用当今趋势和新兴技术的最佳方法仍然不是100％满意或明确。
我想我正在寻求大众社区对于在使用当今.NET技术的大多数方面构建企业应用程序时所选择的方向和架构实现的意见以及您将采取的方向。 我最好把这个关于我和我的问题，因为担心这样做太模糊了; 我想改进我的架构以进行改进，并且非常希望听到你们的想法，因为我将要编写的技术列表。
您建议的任何和所有最佳实践和架构模式都是受欢迎的，如果您之前已经为类似类型的设置创建了解决方案，那么您可能遇到或克服的任何陷阱或警告。
这是我最新项目中采用的技术列表，除了WPF之外几乎所有东西都是:)
- 智能客户端（WinForms）
- WCF
- 由Smart Client使用
- ASP.NET MVC
- 管理工具
- 客户端工具
- LINQ to SQL
- 由WCF使用
- 使用ASP.NET MVC
- Microsoft SQL Server 2008
要考虑的实用程序和其他组件：
- dependency injection – StructureMap
- exception管理 – 自定义
- unit testing – MBUnit
我目前在n-Tier拱门中运行。 采用基于服务的设计模式，利用请求/响应（不确定它的正式名称）和存储库模式，我的大部分结构都是从Rob Conery的Storefront采用的 。
我想我对大多数层级都或多或少感到高兴（这真的只是DAL，我有点不安）。
在我结束之前，这些是我当前架构面临的真正问题：
-
如果我在使用LINQ to SQL时应该有一个自定义数据访问层，那么我有一个很大的问号。 我应该直接在服务/业务层或存储库方法的DAL中执行LINQ to SQL吗？ 您是否应该在每个存储库方法调用中创建数据库上下文的新实例（使用using（））？ 或一个类构造函数/通过DI？
-
在使用LINQ to SQL时，您是否相信我们可以真正使用POCO（普通的旧CLR对象）？ 我很想看到一些例子，因为我遇到了问题，而且对于WCF工作来说特别方便，因为我显然无法通过线路传输L2S对象。
-
通过在视图中保持视图逻辑，控制器调用服务/业务方法以及模型中的数据访问，您自己创建一个ASP.NET MVC项目非常清楚地显示您应该采用的设计模式，但是您是否会放弃模型’对于大型项目而言，特别是在共享数据访问的地方，您将采取什么方法来获取数据？
感谢您的光临，并希望看到基于架构的示例代码库以及它是如何拆分的。 正如我所见，我已经看到了Storefront，我还没有真正通过Oxite，但我认为这对我和每个人都有好处。
在DAL项目符号点中添加了其他问题。 / 15:42 GMT + 10
回答你的问题：
-
我应该直接在服务/业务层或存储库方法的DAL中执行LINQ to SQL吗？ LINQ to SQL特别适用于您的数据库与业务对象进行1对1映射的情况。 在大多数情况并非如此的企业情况下， 实体更合适。
话虽如此，LINQ通常非常适合在您的业务层中直接使用，因为LINQ提供程序（无论是LINQ to SQL还是其他） 是您的DAL。 LINQ的好处是它允许您在业务层中比
DAL.GetBusinessEntityById(id)更灵活和更具表现力，但是使LINQ和传统DAL代码都工作的接近金属的代码被封装远离你，具有同样的积极作用。 -
在使用LINQ to SQL时，您是否相信我们可以真正使用POCO（普通的旧CLR对象）？ 如果没有关于LINCO to SQL的POCO问题的更多具体信息，很难说。
-
你会放弃更大项目的“模型”方面 MVC模式总体而言比ASP.NET MVC可能暗示的表面看法要宽泛得多。 根据定义，您选择用于连接应用程序中的数据支持的任何内容都将成为您的模型。 如果那是利用WCF或MQ连接到企业数据云，那就这样吧。
当我看到Rob Connery的店面时，看起来他正在使用POCO和Linq来SQL; 但是，他是通过将Linq转换为SQL创建的实体到POCO（并返回）来实现的，这对我来说似乎有些愚蠢 – 基本上我们有一个DAL用于DAL。
但是，这似乎是使用Linq to SQL的POCO的唯一方法。
我会说你应该使用一个Repository模式，让它隐藏你的Linq to SQL层（或者你最终用于数据访问的任何东西）。 这并不意味着您不能在其他层中使用Linq，只需确保您的存储库返回IQueryable
无论您是否使用LINQ-to-SQL，对于像WCF这样的事情，使用单独的DTO对象通常都是cmomon。 我在这里引用了一些关于这个主题的想法： 实用的LINQ – 但对我来说，最大的问题是：不要在存储库接口上公开IQueryable / Expression<...> 。 如果这样做，您的存储库不再是黑盒子，并且无法单独测试，因为它是调用者的心血来潮。 同样，您无法孤立地分析/优化DAL。
更大的问题是IQueryable泄漏（ LOLA ）。 例如，entity framework不喜欢Single()或Take()而没有显式的OrderBy() – 但L2S就可以了。 L2S应该是DAL的实现细节 – 它不应该定义存储库。
出于类似的原因，我将L2S关联属性标记为internal – 我可以在DAL中使用它们来创建有趣的查询，但是……