《软件开发技术的选择》由会员分享，可在线阅读，更多相关《软件开发技术的选择（14页珍藏版）》请在金锄头文库上搜索。
1、软件开发技术的选择一、前言作为的研发部，担负本公司产品所有软硬件核心技术的维护、创新与发展的重任，也是本公司的发展壮大的力量源泉。软件研发技术的选择，与我们部门当前与未来的技术发展紧密相关，或者说，与我们的战略规划密不可分。现阶段，我们部门的战略规划是建立有强大创新能力的高效团队，立足彩票行业，不断拓展新的业务领域。 短期目标（未来一年）：以公司市场为导向，配合市场活动，扩大市场份额；同时加强管理，进行相关的技术储备和技术研究，调整和优化自己的组织架构，为公司未来的发展方向打好基础。 中期目标（未来 13 年）：建立良好的管理制度和合理的组织架构后，并结合自己的技术储备开始全面拓展彩票业务，同
2、时公司盈利结构开始发生调整，向软件、系统集成、增值业务开始倾斜，同时开始重点强调业务领先的思路。 长期目标（未来 35 年）：在形成了彩票行业全面的产品结构后，部门重心开始向行业顾问倾斜，服务和业务将成为核心竞争力那么，我们研发部的软件技术研发方向是什么？我个人认为我们的发展方向：面向网络（或者说 Internet） 、面向对象 。二、当前的主流软件研发方向1、为什么不是 C+？C+作为最主要的工业语言标准之一，特别是近几年来，C+ 语言出现了蓬勃的发展，各种新技术和新概念层出不穷，世界范围内的 C+社群也是蒸蒸日上。但是，勿庸讳言的是，C+的地位确实受到了来自 Java/C#的有力挑战。在应
3、用领域、特别是在高端的应用领域中，Java 正在逐渐取代 C+成为主流。导致这种情况的原因是多样的，但最主要的原因有两个。一个是 C+的标准推出太晚，直到 1998 年 ISO C+标准才正式推出，在此之前，各种风格的 C+版本把时间浪费在内耗上，将大片的市场拱手让给了 Java。另一个更重要的原因是，虽然 ISO C+标准的制定统一了 C+的语言，但是却没有统一 C+的 framework。虽然 C+标榜自己是平台无关的语言（它的确也是） ，但是对于同一个问题，在不同的平台下有各种不同的解决方案。C+自己的标准库只是一个语言的 framework，而不是一个应用的 framework：在I/
4、O，多线程，Socket，GUI，数据对象模型等等常见的问题上，开发者们不得不要么自己封装特定平台的 API，要么寻找难以保证质量的第三方类库。没有统一 framework 的C+，就象没有 VCL 的 Delphi，没有 JFC 的 Java，没有 .NET framework 的 C#。因此，除了在某些底层的开发中 C/C+仍然具有不可替代的地位，C+在应用领域无法与 Java/C#抗衡，而逐渐退守到底层编程。对于我们来说，如果确实有必要搞搞 C+，可以考虑 Borland C+BuilderX。因为Microsoft 公司已经下定决心，将操作系统从 Win32 全面转向.NET，.NET
5、 将是 Microsoft 公司解决方案中的统一的编程模型。Borland C+BuilderX 并没有向.NET 靠拢，而是坚持走原生开发工具的道路，并且扩展到了多个平台、多个编译器。Borland C+BuilderX 现在的 framework，完全使用标准 C+整个重新写成，而且支持跨平台和交叉编译（Cross Compilation，即在一个平台下编译生成另一个平台下的可执行代码） ，同时也对某些专业领域，例如嵌入式开发，提供了专门的支持。另外，它还能够方便地挂接 ACE、Loki、Boost 等第三方的 C+库。2、 DOTNET 与 J2EE 的比较1）群力所致的 J2EEJav
6、a 于 1996 年由 Sun 公司推出，当时它的主要用途是制作产生动态网页的 Applet。后来，人们发现 Java 的“一次开发，多次运行” 、纯面向对象的特性、垃圾回收机制和内置的安全特别适合于开发企业应用系统。于是，企业应用开发商纷纷在 Java 标准版的基础上各自扩展出许多企业应用 API，其结果导致基于 Java 的企业应用呈爆炸式增长。但是各企业系统 API 之间又不能相互兼容，破坏了 Java 的平台独立性。鉴于此，Sun 公司联合IBM、Oracle 、BEA 等大型企业应用系统开发商于 1998 年共同制订了一个基于 Java 组件技术的企业应用系统开发规范，该规范定义了一
7、个多层企业信息系统的标准平台，旨在简化和规范企业应用系统的开发和部署。这一规范和其定义的平台就构成了 J2EE。J2EE 是一个基于组件-容器模型的系统平台，其核心概念是容器 。容器是指为特定组件提供服务的一个标准化的运行时环境，Java 虚拟机就是一个典型的容器。 组件是一个可以部署的程序单元，它以某种方式运行在容器中，容器封装了 J2EE 底层的 API，为组件提供事务处理、数据访问、安全性、持久性等服务。在 J2EE 中组件和组件之间并不直接访问，而是通过容器提供的协议和方法来相互调用。组件和容器间的关系通过“协议” 来定义。容器的底层是 J2EE 服务器，它为容器提供 J2EE 中定义
8、的各种服务和 API。一个J2EE 服务器（也叫 J2EE 应用服务器）可以支持一种或多种容器。EJB 是 J2EE 平台的核心，也是 J2EE 得到业界广泛关注和支持的主要原因。我们知道，J2EE 的一个主要目的就是简化企业应用系统的开发，使程序员将主要精力放在商业逻辑的开发上。EJB 正是基于这种思想的服务器端技术，它本身也是一种规范，该规范定义了一个可重用的组件框架来实现分布式的、面向对象的商业逻辑。EJB 的核心思想是将商业逻辑与底层的系统逻辑分开，使开发者只需关心商业逻辑，而由 EJB 容器实现目录服务、事务处理、持久性、安全性等底层系统逻辑。 服务是组件和容器之间，以及容器和 J2
9、EE 服务器之间的接口，在实现层面上它就是一系列 API 和协议 。J2EE 平台定义了一组标准的服务，其中有些服务是由 J2SE 提供的，有些则是 J2EE 对 Java 的扩展。从应用的角度来看，J2EE 为企业应用系统的开发提供了一种多层分布式企业应用模型。在 J2EE 中，应用逻辑按功能不同可以划分为不同类型的组件，各组件根据它们所在的层分布在不同的机器上，共同组成一个基于组件的分布式系统。2）.NET 开发平台留住 Windows 开发者.NET 开发平台一推出，就开始了与 J2EE 平台的竞争。它的绝大部分是微软Windows DNA(Distributed Network Arc
10、hitecture)的重写， DNA 是微软以前开发企业应用程序的平台。Windows DNA 中包括了许多已经被证实的技术，新的.NET 框架取代了这些技术，并包含了 Web 服务层和改良的语言支持。从战略角度看，.NET 开发平台担负着整合.NET 战略的重任，但它最直接的目标则是努力为微软保留住庞大的 Windows 用户基础。微软的 Windows 开发用户群是微软通过 Windows 操作系统获得的最大财富。对于为什么要推出.NET 开发平台，微软表示，主要原因之一就是由于 Java 向开发者承诺的硬件和操作系统无关性，可能会导致这些用户转向其他平台。虽然开发平台本身不会给微软带来很
11、多收益，但 Windows 程序员是企业内部对微软产品的主要支持力量，商用软件的开发者形成了向客户销售微软产品的重要渠道。如果微软可以让开发者在.NET 开发平台上编写应用程序，那么就会有更多的公司购买微软的其他产品。(1)、.NET 框架内核NET 框架实现了语言开发、代码编译、组件配置、程序运行、对象交互等各个层面的功能，为 Web 服务及普通应用程序提供了一个托管、安全、高效的执行环境。所有在.NET 平台上创建的应用程序运行都需要两个核心模块:Common Language Runtime（CLR，通用语言运行时）和.NET Framework 类库。CLR 是一个软件引擎，用来加载应
12、用程序，确认它们可以没有错误地运行，并进行相应的安全许可验证，执行应用程序，然后将被清除。.NET Framework 类库则向程序员提供软件组件，来编写在 CLR 的控制下运行的代码，它们按照单一有序的分级组织提供了一个庞大的功能集，包括从文件系统到对 XML 功能的网访问的每一样功能。(2)、CLR.NET 的虚拟机CLR 为 .NET 应用程序提供了一个托管的代码执行环境。托管意味着将原来由程序员或操作系统做的工作剥离出来交由 CLR 来完成，从而使程序运行获得更高的安全性和稳定性。这些工作包括内存管理、即时编译、组件自描述、安全管理和代码验证，以及其他一些系统服务。CLR 提供一个技术
13、规范，无论程序使用什么语言编写，只要能编译成中间语言，就可以在它的支持下运行，这样.NET 应用程序就可以独立于语言。CLR 还在应用程序运行环境中为基于组件的编程提供了直接支持，比如它支持属性、事件、对象、继承性、多态性、接口等组件编程特性。 CLR 中的自动垃圾收集器负责.NET 应用程序运行时的内存分配、对象布局、内存释放等内存管理问题，彻底解决了多年来困扰程序员的内存泄漏问题，大大增强了应用程序的健壮性。 即时编译器在运行时将中间语言以调用的对象方法为单位动态编译成本地二进制代码。中间语言是在.NET 平台下编译器输出 PE 文件（Windows 可执行文件）的语言，它为.NET 平台
14、提供了多语言支持，允许开发者使用 20 多种不同的编程语言。而元数据是一个内嵌于 PE 文件的表的集合，描述了代码中数据类型等在代码执行时 CLR 需要知道的信息。元数据使得.NET 应用程序代码具备自描述特性，提供了类型安全保障，而这在以前需要额外的类型库或接口定义语言（IDL）。 CLR 根据托管组件的来源（如互联网、企业局域网、本地机器）等因素确定各组件的信任度，并根据信任度来限定它们执行诸如读取文件、修改注册表等敏感操作的权限。此外，CLR 借助通用类型系统对代码类型进行严格的安全检查，可以避免不同组件之间可能存在的类型不匹配问题。通过代码访问安全机制，开发人员可以为应用程序指定完成工
15、作所必需的权限。CLR 不仅规定了代码访问安全，还规定了基于角色的安全。基于角色的认证为互联网上分布式组件的执行提供了安全保证。 值得指出的是，CLR 通常寄宿在其他高性能服务器的应用程序中，比如互联网信息服务器（IIS）、 SQL Server 数据库服务器等。这样，开发者可以充分利用 CLR 诸多安全、高效的优点来部署自己的商业逻辑。(3)、类库组件和服务的家园.NET Framework 类库由一组广泛的、面向对象的、可被开发者用于任何编程语言的可重用类集合组成。它提供了几乎所有应用程序都需要的公共代码;在此之上是许多应用程序模板，这些模板为开发网络站点和网络服务提供特定的高级组件和服务
16、，不管是传统的命令行程序还是 Windows 图形界面程序，亦或是面向下一代互联网分布式计算平台的ASP.NET 或 Web 服务应用。与在 Windows 和它的 SDK 中发送的代码库一样，.NET 框架类库将程序员从繁重的编程细节中解放出来，而专注于程序的商业逻辑。它将核心Win32 API 最常用的功能和外挂 SDK 的功能封装到了一个统一的包中，并采用清晰而有条理的方式对类库进行分组和描述，这样开发者就能够更方便地找到其应用程序所需要的大多数功能。ASP.NET 应用服务体系架构为用 ASP.NET 建立 Web 服务提供了一个高级的可编程模板。虽然建立 Web 服务并不限定使用特定的服务平台，但是 ASP.NET 的许多优点将简化其开发过程。使用这个编程模型，开发人员甚至无需理解 HTTP、SOAP 或其他任何网络服务规范。ASP.NET 可以利用现存的体系架构和应用程序，为在互联网上绑定应用程序提供了一个简单的、灵活的、基于产业标准的模型。3）异中有同同中有
