理想的.NET架构？

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

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

LLBLGEN

亚音速

LINQ to SQL

实体框架

CodeSmith + .netTiers

NHibernate的

手动编码DAL/BLL/Presentation

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

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

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

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

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

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

我的典型工作流程如下:

创建逻辑实体模型

为实体模型创建数据存储

创建数据访问代码和业务对象

创建逻辑/业务层

创建表示层

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

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

我觉得不要太挂了是很重要的3对ň层-如果你在分开以后在多个层次适当延长你的系统的担忧将不会是一个困难的工作.

这样一个广泛(和好)的问题.深呼吸.

不要偏离设计模式,但它们是与架构策略相比的策略.当然要学习它们,但这并不是特别相关.

您在问题中提到的许多内容并不是相互排斥的,可以将其视为整体架构特定部分的子策略.随着时间的推移和经验,我的个人偏好发生了巨大的变化,我仍然完全天真地使用了一些引人入胜的技术,但是我认为只有一个全球性的架构常量:

分离关注点.

这个原则是我认为的"黄金标准",它可以提供许多好东西:单元测试,合同设计,依赖注入,MVC,n层.我说第一步是了解SoC,第二步是通过测试驱动开发来实现它.我认为其他一切都有利有弊,但维护,概念和通过首先识别问题所驱动的架构的好处是毋庸置疑的.

我的书签文件夹不是我想象的那样,但这些是一些在线文章巩固了我对此事的看法:

SoC的重要性

TDD简介

更多关于TDD

IBM参考架构

编辑:从哪里开始使用空白画布？

添加您选择的单元测试库并绘制测试(也称为事实).

测试>设计>代码>转到1