.Net开发中的设计问题和构架

.Net开发中的设计问题和构架
原文地址：http://www.c-sharpcorner.com/Code/2005/March/DesignTechniques.asp
作者：Saradha Gnanavel
应用程序的设计和结构是很重要的，就像其技术细节的实现一样。在开发任何项目之前，我们需要处理一些问题，比如，用什么技术，用什么数据库，应用程序的物理架构等等。这篇文章将提供一些在使用.NET开发中遇到的设计问题的意见。
以下是做企业级开发会遇到的问题：
选择什么语言？
使用什么数据库？
设计和维护用户界面
物理构架
选择什么语言？
可以看到很多关于埋怨.NET的语言。选择的语言需要让我们完成应用程序要求的任务。
考虑到GUI应用和标准业务应用，我们可以选择一个支持良好用户界面的集成开发环境，比如Visul Basic或Visul C#。
同样，如果考虑一个游戏或需要和硬件大量交流的应用系统。在这种情况下我们显然要选择Visual C++而不是Visul Basic或Visul C#。
使用什么数据库？
这由以下因素决定：
◆数据库引擎能力，可能客户端也在一起
◆数据量
◆与其它数据库或服务器的联系是否容易
◆被存储的数据的属性
设计和维护用户界面
一些应用系统比如电子商务，再现购物，社团的网站和企业及应用是为了远程可上网的用户，无疑的需要网页接口或者用户界面接口。但是也有其它的应用系统，用户可以自己选择适合的用户接口。
让我们看看帮助我们选择用户接口的基本要素。
应用系统在以下情况，需要Web用户接口：
◆    远程用户，且用户能访问Internet
◆    是B2B（Business to Business）应用
当有了Web服务器后，可以在不同平台和不同资源间建立良好的无缝链接，以实现应用程序的交流。
◆    是B2C（Business to Consumer）应用
Web应用比桌面应用程序更加容易访问，因为桌面程序只能在局域网中实施链接并分布到网络上的各个节点上，而且每一个PC都要安装客户端程序。
◆    需要输入的数据量和在画面上需要输入的东西相当少
如果有很多的数据需要用户输入，这就需要一个很大的用户控件集，而在桌面程序中更易使用窗体和对话框，这是Win Forms程序要比Web Forms的好。
◆    需要有限的用户接口
◆    需要在画面上显示的数据很少
因为数据和画面样式需要从Web服务器中不断的发送，以满足客户端的请求，所以会使速度变慢。在桌面程序中，界面只向服务器提交一次，而后数据马上就取得回来了。
◆    每个用户有自己的数据
在这种情况下，通过维护sessions和cookies是很容易做到的。
◆    用户喜欢使用滚动条来看数据，而不是使用Tab键
◆    需要一些冗长的画面来表示数据。
◆    配置成本尽可能小的系统
◆    升级成本尽可能小的系统
Web UI提供一个集中的应用配置和升级，这样可以减少配置和升级的成本。
◆    需要经常性的升级。
Web UI也允许使用标准的HTML元素。有些应用需要很高的处理能力。我们可以升级我们的中心服务器，以代替升级各个独立的工作站。
应用系统在以下情况，需要桌面用户接口：
◆    需要和任何特定的硬件连接。
◆    需要支持拖动释放。
◆    游戏或CAD或CAM等应用，需要直接和硬件交流的。
◆    需要大量的用户控件。
◆    通过网络或CD或推进服务器(push servers)可以配置的。
◆    升级可以通过网络或CD或推进服务器（push servers）就可以进行的。
物理构架
以下是.NET应用中可能遇到的构架
◆    两层应用架构
◆    三层应用架构，使用XML Web Service
◆    三层应用架构，使用.NET Remoting
◆    逻辑上的N层应用
◆    N层应用，使用XML Web Service
两层应用架构
客户端应用程序直接使用ADO.NET来连接数据库服务器

这种架构适合小的应用系统，很少的用户接口和简单的业务逻辑。
但是，在一个企业及的应用环境中应用是不合适的。
开发技巧
◆    窗口中的控件直接绑定到数据集中。
◆    也可以使用代码来直接访问数据库，将返回数据手动绑定到控件上。
◆    所有的业务规则随UI一起同步
特征
◆    开发快速且简单
◆    因为业务逻辑和UI是不分离的，升级或修改变得十分繁琐，比如对一些业务的变更，所有的客户端都要更新。
◆    当数据库中有改变或者是一个数据段的名字变了，整个的代码需要改变。改变代码来加载新的数据集将十分困难。
三层应用架构，使用XML Web Service
所有的SQL代码都在Web服务器上，数据集是在服务器上构建的，数据取得后作为一个XML串返回到客户端，在客户端重新构建数据集。
这种架构同时适合于Web应用和Win应用。
这种构架最适合于：我们需要丰富的桌面应用，但是用户是从不同位置连接上来的，并且使用HTTP来获取数据。

特征
◆    开发快速且简单
◆    因为数据库访问逻辑从Web服务中分离，所以访问数据库层可以集中升级。
◆    很小的维护开销
◆    因为业务规则没有从UI中分离，升级或更改还是比较繁琐，比如，任何业务的更改都需要所有客户端的更新。
◆    客户端必须能访问网络（因为需要连接Web服务器）
这种架构在一定程度上适合Internet应用。
三层应用架构，使用.NET Remoting
所有的SQL代码都在远程服务器（Remoting Service）上，数据集在服务器上构建，然后作为XML数据返回到客户端，并在客户端重新构建数据集。也可以写代码来处理从远程组件返回来的数据，手动的绑定到窗口的控件上。
这种构架适合在局域网中分布的计算机。在局域网环境中，.Net Remoting可以作为数据存取层。
所以这种构架适合Intranet中的应用。

特征
◆    开发快速且简单
◆    因为数据库访问逻辑的分离，数据访问层可以集中更新
◆    很小的维护开销
◆    因为业务规则没有从UI中分离，升级或更改还是比较繁琐，比如，任何业务的更改都需要所有客户端的更新。
◆    用户可以从局域网或广域网中的任何一个节点来使用这个应用。
逻辑上的N层应用
这种架构包括客户端应用、业务规则组件、数据层组件、物理数据库。这是所有.NET开发的最好的方法。

特征
◆    将业务逻辑层分离出来集中管理
◆    任何组件或层都可以移植到其他机器上，这样改善了升级和集中化管理。
◆    开发需要相对长的时间，但是这并不是问题，因为一旦开发出来将是十分富有成效的。
N层应用，使用XML Web Service
一个XML服务器用来做数据层。通过HTTP层将数据集类型返回到业务逻辑层。客户端将数据集处理后先是给用户。

当数据层集中管理，客户端是Web或Windows应用的时候，这是极好的方法。