我是从ASP.NET应用程序的角度来编写这个问题的。但是我意识到它也适合其他环境。
开发ASP.NET网站的常用元素有很多方法。以下是我遇到的一些问题：
我不认为自己是专家开发人员，但我确实理解常见的OOP技术，并且可以很好地完成我的所有项目。然而，我确实知道如何“架构”一个网站。我的意思是，我应该使用 n-tier architecture？这仍然是黄金标准，上述工具只是利用了这个概念吗？我很确定我想推迟MVC，直到未来（或最终）发布。
*****编辑：在完全理解问题的分离之后，我已经删除了处理模式（单身，工厂）的问题部分。感谢所有已回答此部分的人，但是，我主要关注的是架构部分。*****
编辑＃2：当我意识到这将不仅适用于特定于网络的架构时，我将标题更改为不可知的问题。
问题：当我坐在空白画布（解决方案文件）前面，我手头有所有预先编写的文档和系统要求时，我会采取哪些步骤作为第一步？我从哪里去？
答案 0 :(得分：7)
我认为您概述的每种方法都有其优点和缺点。您选择的将是个人偏好，团队成员的经验和项目类型 - Linq2Sql非常适合快速启动和运行，但可能不适合大型和/或复杂的企业项目，例如..你能做的最好的事情就是尝试一下并了解它们。
至于模式，它们以经过验证的方式帮助解决特定问题和反复出现的问题。它们还有助于熟悉未编写代码的开发人员。如上所述，值得尝试一些，以了解他们做什么以及何时使用它们 - 但他们解决特定的编程问题而不是架构模式。
我的典型工作流程如下：
我通常会将数据访问和业务对象，业务逻辑和演示文稿（网站/ winforms）分成他们自己的项目，而且我以后可能想要重复使用的任何内容也都在自己的项目中。我还有一个包含公共扩展和接口的Base项目，我几乎在我所做的每件事情中都重复使用它。
在架构方面，我尝试确保我的项目松散耦合，以便您可以轻松地从三层架构移动到n层架构。松散耦合还意味着您可以切换后备存储，并且您需要做的就是编写一个新的数据访问层，其中所有逻辑和表示代码保持不变。
我认为重要的是不要太忙于三而不是 n 层 - 如果您将您的问题分开，那么以后将您的系统扩展到多个层级将不会这是一项艰难的练习。
答案 1 :(得分：5)
这么广泛（和好）的问题。深呼吸。
不要偏离设计模式，但它们是与架构策略相比的策略。当然要学习它们，但这并不是特别相关。
您在问题中提到的很多内容并不是相互排斥的，可以将其视为整体架构特定部分的子策略。随着时间的推移和经验，我的个人喜好发生了巨大的变化，我仍然完全天真地使用了一些引人入胜的技术，但是我认为只有一个全球性的建筑常数：
关注点分离。
我认为这个原则是你的“黄金标准”，它提供了许多好东西：单元测试，合同设计，依赖注入，MVC，n层。我说第一步是了解SoC，第二步是通过测试驱动开发来实现它。我认为其他一切都有利有弊，但维护，概念和通过首先识别问题所驱动的架构的好处是毋庸置疑的。
我的书签文件夹不是我想象的那样，但这些是一些在线文章巩固了我对此事的看法：
编辑：从哪里开始使用空白画布？
添加您选择的单元测试库并绘制测试（也称为事实）。
测试＆gt;设计＆gt;代码＆gt;转到1
答案 2 :(得分：3)
我个人是n层架构的粉丝。当我开始时，我通常会为Web应用程序创建两个项目，第一个用于业务逻辑和数据库访问，这是一个类库项目。然后我为实际网站添加了一个Web应用程序项目。
我过去构建了一个数据访问框架，我使用该框架利用Microsoft数据应用程序块进行所有数据访问，这就是我用来构建所有数据调用的方法。
我有时会使用codemith或其他项目，但到目前为止，我已经找到了更好的运气，只是滚动我自己的代码，因为我可以更加细化数据。如果我有时间研究其他ORM工具，我可能不需要担心它......
我发现最好的方法通常是创建业务对象，数据验证和应用程序的所有“业务”部分。然后在数据访问部分中编程，并通过将所有内容与表示代码放在一起来完成。能够做到这一点需要一些纪律，但它确保你以一种可以重复使用的方式构建东西，并且我取得了巨大的成功。
你引用的那本书可能也是一个很好的例子。
从评论中添加
回应发布的评论。通常在我的Business / Data类库中，我将使用命名空间将逻辑与数据分开。这里有一些关键的事情。
我的数据方法调用的范围都受到程序集的限制，它们不是可以直接调用的项目，这样我就可以通过所有演示文稿调用者的业务逻辑强制执行数据访问
所有数据输入和输出都是通过对象完成的，而不是数据集或任何其他变体
验证后的Business方法将调用数据组件中的特定方法以获取所需信息。
答案 3 :(得分：0)