关于此次团队项目中技术选型问题
2016-03-29 17:47
274 查看
关于此次软件项目的开发,我们设计了一个软件应用型的项目。显然,我们的项目跟市场上的主力军项目来比,就像一个刚出蛋壳的小鸡,很多地方都有可能出现纰漏。但是,在信息技术多元化发展的今天,我们必须给予项目技术层面足够多的关注,不然的话,吃亏的只能更加是自己。下面是此次项目开发中的关于技术选型方面的历程:
最初我们打算的项目是网站型的项目,因为网站性的项目访问量可能会比较大,而且还总是受到网络速度的影响,所以我们在选择框架时在前端WEB层中选择了Model View Controller(MVB)。之所以不选择最近士气高涨的事件驱动型框架是因为这样的框架比较复杂,项目在运行的过程中容易产生较多的对象,而且网络传输的数据量也大,这样的话,中间件服务器将承受不住这样大的访问量。MVC中的STRUTS相对而言比较适合网站性的项目,这样可以方便我们控制客户端和服务器端传输的数据量,尽可能减小他们之间的数据量,以便减轻服务器的负担。我们的项目是新生的产品,由于时间限制感觉并不能开发出STRUTS这类型的框架,所以我们用到缓存技术,至于效果如何,我们现在还不能估测。
考虑到持久层这一点的时候并没有什么想法,不得已只好去网上搜寻资料。简单的JDBC,也就是Java数据库连接,初学者一般都选择它。JDBC基本不耗费,而且很容易被控制,这样一来,客户端与服务器端的数据量就能够保持在一定范围内,这是网站型项目的首要选择。
实际上,这个项目需要用到什么技术并不是那么重要,关键是在于我们以怎样的心态去开发这个项目。只要团队携手并肩,勇往直前,任何难题都会迎刃而解,不管项目用到什么技术都可以变得很优秀,因为它承载着我们的希望!
最初我们打算的项目是网站型的项目,因为网站性的项目访问量可能会比较大,而且还总是受到网络速度的影响,所以我们在选择框架时在前端WEB层中选择了Model View Controller(MVB)。之所以不选择最近士气高涨的事件驱动型框架是因为这样的框架比较复杂,项目在运行的过程中容易产生较多的对象,而且网络传输的数据量也大,这样的话,中间件服务器将承受不住这样大的访问量。MVC中的STRUTS相对而言比较适合网站性的项目,这样可以方便我们控制客户端和服务器端传输的数据量,尽可能减小他们之间的数据量,以便减轻服务器的负担。我们的项目是新生的产品,由于时间限制感觉并不能开发出STRUTS这类型的框架,所以我们用到缓存技术,至于效果如何,我们现在还不能估测。
考虑到持久层这一点的时候并没有什么想法,不得已只好去网上搜寻资料。简单的JDBC,也就是Java数据库连接,初学者一般都选择它。JDBC基本不耗费,而且很容易被控制,这样一来,客户端与服务器端的数据量就能够保持在一定范围内,这是网站型项目的首要选择。
实际上,这个项目需要用到什么技术并不是那么重要,关键是在于我们以怎样的心态去开发这个项目。只要团队携手并肩,勇往直前,任何难题都会迎刃而解,不管项目用到什么技术都可以变得很优秀,因为它承载着我们的希望!
相关文章推荐
- Xcode7 使用NSURLSession发送HTTP请求的问题
- java的序列化与反序列化及transient关键字
- 1-100的Catalan数
- javaer to go之基础
- git diff查看差异
- word embedding
- 328-m-Odd Even Linked List
- VM模板学习
- java.lang.NoClassDefFoundError: org/apache/commons/lang3/StringUtils
- mysql存储过程笔记
- Mybatis入门例子
- activity间传送bitmap的办法
- <c:forEach>循环list,<c:if>判断奇偶
- Android常见文件路径介绍
- MAC下Eclipse的启动
- eclipse 入门级使用
- 欺壹世充电系列之[Svn集中式版本管理系统] 推荐
- MySQL测试SQL执行的速度测试
- Codeforces 544E Remembering Strings 状压dp
- 第四次作业