理想的.NET体系结构?[闭门]

至于模式,它们有助于以经验证的方式解决特定的和重复出现的问题。它们还帮助没有编写代码的开发人员熟悉。如上所述,值得尝试一些方法来了解它们的用途和使用时间,但它们可以解决特定编程问题,而不是架构模式。

我的典型工作流程是:

• 创建逻辑实体模型
• 为实体模型创建数据存储
• 创建逻辑/业务层
• 创建表示层

我通常会将数据访问和业务对象、业务逻辑和表示(web站点/winforms)拆分为它们自己的项目,另外,我可能希望在以后重用的任何内容也会包含在它自己的项目中。我还有一个基本项目,其中包含我在几乎所有工作中重复使用的通用扩展和接口。

在体系结构方面,我尝试确保我的项目是松散耦合的,以便您可以轻松地从三层体系结构转移到n层体系结构。松耦合还意味着您可以切换备份存储,只需编写一个新的数据访问层,所有逻辑和表示代码保持不变。

我认为重要的是不要太挂断电话 N

这是一个如此广泛(而且很好)的问题。深呼吸。

关注点分离

我认为,这个原则是你的“黄金标准”,它告诉了你很多好东西:单元测试、契约式设计、依赖注入、MVC、n层。我说第一步是理解SoC,第二步是通过测试驱动开发来实现它。我认为其他一切都有利弊,但维护、概念和由首先认识问题驱动的体系结构的好处是毋庸置疑的。

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

• The importance of SoC
• Intro to TDD
• More on TDD
• IBM piece on Reference Architecture

编辑:你从空白画布开始哪里?

添加您选择的单元测试库,并勾勒出测试(也称为事实)。

我个人是n层体系结构的粉丝。当我开始时,我通常会为一个web应用程序创建两个项目,第一个用于业务逻辑和数据库访问,这是一个类库项目。然后,我为实际的网站添加一个web应用程序项目。

在过去,我构建了一个数据访问框架,我使用它来利用Microsoft数据应用程序块进行所有数据访问,这就是我用来构建所有数据调用的结构。

我发现最好的方法通常是创建业务对象、数据验证和应用程序的所有“业务”部分。然后在数据访问块中编程,最后将所有内容与表示代码放在一起完成。要做到这一点需要一定的纪律,但它可以确保你以一种可以重复使用的方式构建东西,我已经取得了巨大的成功。

你提到的那本书可能也是一个很好的例子。

作为对一条评论的回应。通常在我的业务/数据类库中,我将使用名称空间将逻辑与数据分开。这里做了一些关键的事情。

2. 所有数据输入和输出都是通过对象完成的,而不是数据集或任何其他变量

3. 验证后的业务方法将从数据组件调用特定的方法以获取所需的信息。

Link