理想的.NET架构?

我是从ASP.NET应用程序的角度来编写这个问题的.但是我意识到它也适合其他环境.

开发ASP.NET网站的常用元素有很多方法.以下是我遇到的一些问题:

> LLBLGen
> SubSonic
> LINQ to SQL
>实体框架
> CodeSmith .netTiers
> NHibernate
>手动编码DAL / BLL /演示

我不认为自己是专家开发人员,但我确实理解常见的OOP技术,并且可以很好地完成我的所有项目.然而,我确实知道如何“架构”一个网站.我的意思是,我应该使用
n-tier architecture?这仍然是黄金标准,上述工具只是利用了这个概念吗?我很确定我想推迟MVC,直到未来(或最终)发布.

*****编辑:在完全理解问题的分离之后,我已经删除了处理模式(单例,工厂)的问题部分.感谢所有已回答此部分的人,但是,我主要关注的是架构部分.*****

编辑#2:当我意识到这将不仅适用于特定于网络的架构时,我将标题更改为更不可知的问题.

问题:当我坐在空白画布(解决方案文件)前面时,我已经采取了哪些步骤作为第一步,我手头有所有预先编写的文档和系统要求?我从哪里去?

我认为你提出的每种方法都有其优点和缺点.您选择的将是个人偏好,团队成员的经验和项目类型 – Linq2Sql非常适合快速启动和运行,但可能不适合大型和/或复杂的企业项目,例如..你可以做的最好的事情是尝试一些并了解它们.

至于模式,它们以经过验证的方式帮助解决特定问题和反复出现的问题.它们还有助于熟悉未编写代码的开发人员.如上所述,值得尝试一些,以了解他们做什么以及何时使用它们 – 但他们解决特定的编程问题而不是架构模式.

我的典型工作流程如下:

>创建逻辑实体模型
>为实体模型创建数据存储
>创建数据访问代码和业务对象
>创建逻辑/业务层
>创建表示层

我通常会将数据访问和业务对象,业务逻辑和演示文稿(网站/ winforms)分成他们自己的项目,而且我以后可能想要重复使用的任何东西也都在自己的项目中.我还有一个包含公共扩展和接口的Base项目,我几乎在我所做的每件事情中都重复使用它.

在架构方面,我尝试确保我的项目松散耦合,以便您可以轻松地从三层架构移动到n层架构.松散耦合还意味着您可以切换后备存储,并且您需要做的就是编写一个新的数据访问层,其中所有逻辑和表示代码保持不变.

我认为重要的是不要太过于挂在三层与另一层之间 – 如果你将你的问题分开,适当地将你的系统扩展到以后的多个层次并不是一件困难的事情.

相关文章
相关标签/搜索