october731
- 浏览: 86537 次
- 性别:
- 来自: 上海
-
最新评论
-
tod17031：
好，学习了。
The resources 4 download -
shevliu：
出于性能等方面的考虑，适当的冗余是合适的。实际项目中会有很多看 ...
讨论 数据库建表中存在数据的互相包含情况，这样合理吗？ -
jmu：
没有主键不能保证数据有唯一标识 也就是不保证符合第一范式没有 ...
新到公司，发现数据库表建立的时候没有主键与表与表之间没有外键？ -
Blithe：
没外键见过在写sql语句的时候用连接就行了 加上where语句 ...
新到公司，发现数据库表建立的时候没有主键与表与表之间没有外键？ -
yhjhoo：
问一句，spring依赖注入是通过接口吗？？
或者说spri ...
接口存在的意义只在于接口依赖注入
文章列表
这个模型层，在实际的开发中，是对数据库表的映射，还是对页面层数据的映射多一点？个人认为在实际的开发当中，真正对数据库表的映射逻辑层类实例化对象用的比较少，而实际的页面对象层才是真正用的多的。不知道在大家的开发经验以及所遇到的项目当中是如何处理这个问题的。
我个人之前遇到一个MVC的项目，是spring+hibernate的，模型层实际上是两种类型的实体类都包含了。对表映射的实体类，叫做Domain；对可变数据实体的映射的实体类，叫做DTO。但是在我们实际的开发过程当中，感觉还是DTO对象用的多的多，因为每一个页面的业务不同，返回的结果相对于单纯的数据库表已经有千差万别，并且数据绝 ...
以至于开始怀疑接口存在的意义。
首先讨论接口和抽象类两者的特点。
接口，定义方法，方法不能实现，这些方法在实现的时候必须是public，也就是我们通常所说的接口定义动作。接口不能定义属性。
抽象类，比较灵活。可以定义私有的方法，并且可以定义普通的方法。如果一定要约束子类必须要实现的方法，可以直接用abstract来修饰。但是抽象类内部的方法不一定要全部都是abstract，也就是说，抽象类内部的方法可以有自己的实现。
简单的结合自己当前的经历分析了一下，觉得接口能做的事情，用抽象类都可以实现。就算是在完成多态的时候，多态的那个对象不管用抽象类来定义还是用接 ...
在MySQL里面如何写一个存储过程或是方法，让他返回一个临时表的数据。要求是这样，存储过程的参数是起始日期和终止日期，比如2008.10.12和2009.5.4，那么是需要他返回的临时表形如：
200810
200811
200812
200901
200902
200903
200904
200905
请问这个该如何实现呢？最好是能够给出代码，谢谢了！
准备系统里面所涉及到的数据库表，建表时都采用这样的方式，主键统一的采用int型的字段“seq”，然后表中都有字段“status”表示信息有效性状态。
在插入数据时主键采用获取最大seq并+1的方式，但是不采用自增列，这样更加灵活一些；然后出于逻辑删除的考虑，status取值有三种，“T”、“F”、“D”，三个状态字符分别表示这条数据当前的状态分别为“有效”、“无效”、“删除”。这样好吗？不知道有没有师兄在建表的时候采用这种方式来做的，并且这种方式还有哪些欠考虑的地方？哪些不足的地方？请各位师兄指点。
做酒店信息系统管理的，之前的程序员在设计客人信息表和会员信息表的时候，采用的是这样的方法：客人信息表主键：GuestNo，表中有一个字段CardNo用来表示会员卡号；会员信息表主键CardNo，而表中又有一个字段GuestNo用来表示这个会员卡号表示的客人编号。我从一开始接触到这个的时候就觉得这个不合理了，但是她们一直都认为这个必须要这样做。我认为只需要在一张表中包含另外的一个表的主键信息就够了，没有必要这样互相包含，也没有意义。比如，直接在会员卡信息表里面包含客人编号就行了，那么客人信息表就只记录客人的基本信息（如地址、姓名等等之类）；或者在客人信息表里面包含会员卡号就行了，那么会员信 ...
项目是spring+Hibernate的，当然了，也是采用的NVC三层架构。这里我主要想不透的一点是其模型层，也就是数据层的问题。在此抛砖引玉，引出大家的看法。
模型层主要是有两种对象，一个的Domain，一个的DTO（Data Transport Object）。Domain是用作相对的数据库表的一一映射的，里面完成了相应的简单的对于一张特定的表的增删改查；DTO是针对页面来设计的，DTO里面的数据以页面为单位，一个DTO里面的字段和属性就是针对于具体页面层的所需要的数据来设置的，也就是说，一个页面对应一个DTO（WebForm1>WebForm1_DTO,WebFor ...
首先说明，虽然我不是做Java的，但是也很喜欢上je，以一个程序员的身份来和大家讨论问题，希望能得到大家的共鸣。
到现在已经工作一年了，记得才毕业的时候，是想找一个专业的软件公司好好的培养自己的。但是到现在为止，已经是第二份工作了，依然不是正规的软件公司。我不知道我的这条路走下去结果会不会是我当初期望的那样。至少我现在已经开始在怀疑这一点了。我简单的描述一下自己的目前经历过的状态，请大家评论，畅所欲言，欢迎大家批评。
我软件工程本科08年毕业于**大学（是一所985和211工程院校），毕业的时候第一份工作是在上海，一个服装公司里面的IT部里面工作。工作的内容是：公司的两套系统当中的一套 ...
是这样的，新到公司，才入职第二天，发现公司系统运行的数据库竟然没有主键与外键，我问我们的主管，他说是因为为了后期的扩展，如果加上键，则会有很多限制。但是我觉得在最初的时候，最好还是有主键外键比较好吧，这毕竟都是良性的约束。而现在正式库和测试库的表结构和表与表之间的关系都是一样的——没有键，而且系统已经在上面开发了很长时间了，数据量也很大了，我觉得已经到了这个时候，就算谁想往里面添加约束，估计也不是那么简单的事情了，肯定会丢失很多实际重要的数据。我的想问的问题是，在数据库建立之初就形成的这种不需要主键和外键的作法，是否在很多项目中都是这样的？小弟目前见识比较短浅，只碰到三个项目，而没有主键外键约束 ...
我是08年本科毕业的学生，本科期间成绩不算太好，但是自认为该学的东西还是学到了的，并且每次项目实践都是自己人组长，并且担当编码的工作，大学的时候C++的小项目做过，C#的项目做过，J2EE的项目做过，但都是最多有三个月的参与时间，毕竟不是商业项目。现在已经在上海工作了快一年了。这里一年的合同差不多快要结束了，是续签，但是薪水的涨幅不大，并且最主要的一个原因是在这里干下去自己感觉没有多少升上去的空间。所以决定跳。但是考虑到两个因素，一来自己的学校（自己并不自卑，但是相比交大，南大这些学校来说，名气还是小了点）不那么出名，只是西南地区的一个重点的211工程985工程的理工科一本；二来这一年呆的公司也 ...
公司的项目分层，是公司自己搭建的框架，分为form层、web service层、biz层，其中biz层负责访问数据库，web service负责调用biz层，而form层则不和biz直接打交道，而调用的是ws层。在这当中，经常会用到这种情况。其实form层需要调用的方法，其实在ws和biz层使用的都是同名的方法，这样也方便调用。本来这样也无可厚非，而且还更不容易出错。但是这样，业务模块多了之后也发现另外一个问题。因为各层的方法名以及方法参数几乎一摸一样，在开发的时候，写每层的方法还可以直接copy和paste，但是一旦修改起来，这可就麻烦大了。重复工作量大。而且最要命的是方法不修改，但是修改参数 ...
很疑惑的是，现在的基于GAE的应用，关于后台的数据库方面是如何处理的。虽然Google提供了每个月100w的pv和500M的容量，但是Google的服务器出了支持python和java的开发之外，我的数据库也可以建立在Google上面吗？想知道在Google上开发的应用，这些数据是存储在什么地方的呢？
1. 自己租用数据库服务器？
2. 用xml保存在Google服务器上？
3. Google支持安装小型数据库如MySQL、SQLite？
愿闻其详。
- 2009-04-13 16:00
- 浏览 1250
- 评论(1)
关于接口存在的意义，之前有一篇帖子讨论过（http://www.iteye.com/post/957921?page=1），并且跟帖无数，我也看过，这里发表一点自己的看法。抛砖引玉。
我的立场是站在spring的依赖注入的角度上来思考这个问题的。个人认为，接口存在的意义只在于接口依赖注入的时候得到淋漓尽致的体现。至于其他时候，作用则并不是那么大了。其理由如下：
1. 在非接口注入的情况下，接口的定义，某种程度上可以理解为对类的一个总的设计，因为其方法并不需要实现，所以可以更多的去思考业务上的逻辑问题，一方面更多心思的去想如何把功能点设计的更加全面，另一方面当我们在实现这个接口的时候，就会受到这 ...
不知道各位做过C/S的MIS管理系统的师兄们，当时你们的项目在解决这个问题的时候是怎么处理的。我先描述一下我所遇到的两次项目的情况（都是用的c#），抛砖引玉。
我所说的条件控制，就是每个页面上的conditions control，每个页面需要查询数据，但是需要指定具体的条件，也就是一些textbox、combobox之类的控件，然后查询就根据这些控件里面的取值来传入参数到存储过程，最后返回数据到页面的grid进行绑定。
A. 第一次做的公司财务报表管理系统。里面的每个人的业务，主要是以页面为单位的。在初始化conditions control（一下简称cc）的时候，比如combobox里面的 ...
在韩国人的手下办事。总共有二十多个左右的中国开发人员，比较初级的，差不多都是应届毕业生的，我也是。韩国那边拿过来的开发文档，因为设计时间仓促等原因，存在的issues非常的多。我们开发人员在北京，设计人员在韩国。开发人员在按照文档开发过程中经常发现新的issues，但是提交到韩国解决的速度又非常缓慢。韩国那边开发的文档基本上是涵盖了页面开发，到控制层，以及数据库访问（存储过程已经由韩国人写了，但是还是经常改动），我们开发基本上是不需要理解业务，只要按照文档来开发就是了。说白了，我们就是韩国人的廉价劳动力。说实话，如果文档是准备的比较周全，那么开发起来确实也只是行云流水的事情，问题是issues不 ...
这段时间在北京这边做开发，是在.NET 平台上的spring.net+NHibernate+SQL SERVER 2008的集成的开发。
由于是spring的技术，所以这个项目有很浓厚的MVC是缩影。我们现在的开发模式是这样：MVC模式三层都有我们A方这边的程序员开发，我们的查询业务基本上依赖于SP，SP由B方方面开发，但是由于需求做的不完善，以及B方方面对需求的理解的不完善，导致SP经常改动。但是SP的每次改动了之后，我们开发应用程序这边的程序人员却不知道，除非是这边的程序员去调试以前已经开发好的程序，不然基本上是很难发现他们修改了存储过程。而且，存储过程的修改，带来的不仅仅只是页面表现层的 ...