GON*_*ale 9 .net c# architecture design-patterns linq-to-sql
我正在避免在.net arch/n-tier体系结构上编写看起来像另一个线程的东西,但请耐心等待.
在选择用于企业应用程序的体系结构时,我希望与其他人一样,对于采用当今趋势和新兴技术的最佳方法仍然不是100%满意或明确.
我想我正在寻找的方向质量社会舆论和建筑实现您构建利用今天的.NET技术和什么方向最方面你会采取一个企业应用程序时会选择.我最好把这个关于我和我的问题,因为担心这样做太模糊了; 我希望改进我的架构以进行改进,并且非常希望听到你们在我将要编写的技术列表中的想法.
您建议的任何和所有最佳实践和架构模式都是受欢迎的,如果您之前已经为类似类型的设置创建了解决方案,那么您可能遇到或克服的任何陷阱或警告.
这是我最新项目中采用的技术列表,除了WPF之外几乎所有东西都是:)
要考虑的实用程序和其他组件:
我目前在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吗？只有当您的数据库与业务对象进行1对1映射时,LINQ to SQL才有意义.在大多数情况并非如此的情况下,实体更合适.
话虽如此,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 的 Storefront 时，他似乎正在使用 POCO 和 Linq to SQL；然而，他通过从 Linq to SQL 创建的实体转换为 POCO（并返回）来实现这一点，这对我来说似乎有点愚蠢 - 本质上我们有一个用于 DAL 的 DAL。
然而，这似乎是将 POCO 与 Linq to SQL 结合使用的唯一方法。
我想说你应该使用存储库模式，让它隐藏你的 Linq to SQL 层（或者你最终用于数据访问的任何内容）。这并不意味着您不能在其他层中使用 Linq，只需确保您的存储库返回 IQueryable<T> 即可。
| 归档时间： |
|
| 查看次数： |
5823 次 |
| 最近记录： |