S**********C
发帖数: 161 | 1 真服了，看来你完全没有领会到Abstract Classs和Interface为什么存在，
不是说你不写这些新的框架，就不需要用这个，他们代表的是一种软件的设计思想，
(不是任何一个系统都是做个web,然后来个database CRUD就完了)
咱不要言必称EJB,Pattern,BPEL,EAI，balabala了，先拿最简单的讨论,
java.util.xxx 里面的AbstractList,AbstractMap这些如果不写成Abstract class,
java.sql.xxx 里面的ResultSet,Statement这些如果不写成interface,
很想请教一下你的高见,你有什么更好的方法去写？ |
|
J*******n
发帖数: 2901 | 2 有一点我是同意你的看法的，继承关系慢慢地在被annotation/injection based API所
替代，现在有些开源的技术，因为要应对大量用户各种各样不同的需求，这时候对灵活
性的要求非常高，如果还要求用户必须继承抽象类甚至实体类是有一些不必要的限制的
。而在大多数不要求应对大量用户需求的Java项目，继承关系还是非常简单直观的一种
实现方式，尽量减少层次当然是好的，但从接口到实体类，3-5层的继承不至于会变得
多shitty，代码得到了很好的reuse，要改起来也方便
我这个abstract class的实例是经过一些简化的，因为我以为你只是要我举个简单的例
子然后展示一下怎么转换成annotation based，结果获得了一些关于我API设计的评论
。。
关于abstract class命名，我这个AbstractComponentPresenter还implement了好几个
接口，比如Configurable，HasConfigurationChangeEventHandlers，
HasStateChangeEventHandlers，ComponentConst... 阅读全帖 |
|
S**********C
发帖数: 161 | 3 我不是跟你说过了java.util.xxx,里面的吗? 举那个例子是因为大家都知道，
你又说"我又不搞framework,balabala，然后又扯上什么session factory"
大哥，我感觉你好像觉得java的工作要么就写spring framework这一类，
要么就是web+Database CRUD这一类，没有其它了？
要么这样吧，我来一个简单的设计题，请教一下如果你不用interface和abstract
class,
怎么实现什么类重用，规范不同implementation之类的基本思想。
现在需要将一个BalanceSheet对象export到一个文件，输出文件格式是csv和excel,
设计的时候要求支持扩展性，比如我将来要支持export IncomeStatement, 或者
Cashflow.
同时需要支持新的格式，pdf,或者excel 2007.
很简单一要求，完全不用在乎BalanceSheet里面是什么，怎么写成pdf这些细节，就是
要个设计思路。不要又扯回什么session bean, stateless what so ever. |
|
c*********e
发帖数: 16335 | 4 service.
我一般做个servicelocator,然后servlet就用servicelocator里面的static method.
这些static method就是做crud |
|
z****e
发帖数: 54598 | 5 短期内还是会用到
sql是学db的基础，但是现在越来越不需要你去手写sql了
平常复习一下左连接右连接就好了
还有crud这些基本操作
appengine沒有用db，所以用不到hibernate
现在持久化的做法是可能不采用传统的关系型数据库
因为多数时候数据是独立的，并不是关联数据
独立的数据可以单独存放，就没有必要每一次都去select一把
一旦涉及到海量数据，select的效率就会逐步降低
select至上再搞transaction就非常恶心了
其实这种割裂的，分离的模块化的思想从始至终都是软件工程这门学科的核心思想
在搞完了middleware之后，这批人开始对db动手了
因为现在主要系统瓶颈都在db这一块上
其实很多年以前我就在尽量减少对db的依赖，各种db的功能
比如store procedure之类的我用得很少，就跟javascript我用得也很少一样
大多数逻辑都集中在java代码上去处理，其它的层面都做比较简单的操作 |
|
z****e
发帖数: 54598 | 6 短期内还是会用到
sql是学db的基础，但是现在越来越不需要你去手写sql了
平常复习一下左连接右连接就好了
还有crud这些基本操作
appengine沒有用db，所以用不到hibernate
现在持久化的做法是可能不采用传统的关系型数据库
因为多数时候数据是独立的，并不是关联数据
独立的数据可以单独存放，就没有必要每一次都去select一把
一旦涉及到海量数据，select的效率就会逐步降低
select至上再搞transaction就非常恶心了
其实这种割裂的，分离的模块化的思想从始至终都是软件工程这门学科的核心思想
在搞完了middleware之后，这批人开始对db动手了
因为现在主要系统瓶颈都在db这一块上
其实很多年以前我就在尽量减少对db的依赖，各种db的功能
比如store procedure之类的我用得很少，就跟javascript我用得也很少一样
大多数逻辑都集中在java代码上去处理，其它的层面都做比较简单的操作 |
|
|
|
z*******3
发帖数: 13709 | 9 效率都不怎么高，现有的效率是建立在对一些常用功能的约定俗成上
比如crud，就可以高效处理，因为都差不多
但是自己要去实现一些界面上的功能
那效率就低了，如果再搞点什么多线程之类的，麻烦就来了
如果再上点soap之类的，你就发现，还不如上java吧，因为往往只有现成java toolkit
当然这是backend，一般不是front end
而且php效率也不低
如果只是做一个论坛的话，有现成的东东
那过来改改就可以用了，连开发都不用，多便捷？
你看新浪什么不还在坚持用php？
如果退化成web service那就更简单了
尤其是rest的web service那就是超级简单了
把html换成xml就好了，连额外的包都不用加
而且前后端一旦分离，真正的逻辑处理在backend上
frontend就负责做一些简单的web层面的处理就好了
这个算是简单得不能再简单得功能了，php足够了
html这些不是说要被替换掉，能用他们搞定的，尤其是基础功能
还是要坚持用这些东西，但是不能寄予太高的期望
做什么diablo，用js就是纯粹找死了，因为他们还不够成熟
我玩过植物大战僵尸的html5版，但... 阅读全帖 |
|
z****e
发帖数: 54598 | 10 用来简化crud开发
groovy写这些常规操作很像脚本 |
|
z****e
发帖数: 54598 | 11 immutable是为了控制transaction
big data如果都上transaction，一定挂
所以干掉crud里面的ud，目的就是为了尽量减少transaction的使用
这其实跟内森不内森关系不大，只要是big data，就应该尽量干掉ud |
|
m******c
发帖数: 830 | 12 谢谢大家的回复。我们最后用了apache shiro， 它里面有个HttpMethod＊Filter，把
HttpMethod 自动map成 CRUD operation，然后可以config path URL mapping as
／app1/** myFilter[privilege1]
／app2/** myFilter[privilege2]
这样如果有request as
POST ／app1/**
shiro就会把它的 privilege requirement转化成
privilege1:create
如果user有这个privilege， 就go，不然blocked。
嗯，我觉得学RESTful 最好看HTTP specification。
现在很多framework 都提供RESTful service， apache CXF， resteasy 啥的 |
|
g*****g
发帖数: 34805 | 13 这本身说的就是缺乏常识，在服务器端跑的东西，有多少装上千份的？
在科学计算的领域之外，大约也就DB，app server, content management
server, ERP这类少数比较标准化的东西算得上。服务器端的东西本来就是
针对一群人的，而一群人的需要会与另一群人不同。即便是上面说的这些
标准化的东西，也只有瓶颈的一小块东西会用C/C++的语言去实现，比如
DB的内核。
几乎任何行业都使用应用服务器，并且大部分行业都是CRUD基础加一些
各行业相关的商业逻辑。应用体系结构可以不同，但本质都是
request/response。最重要的无非就是security, transaction, scalability，
reliablity这些概念，这些远远比单机的performance重要的多。
C++因为语言本身的原因，在scalability和reliability上有很大缺陷。
所以新的服务器应用很少再用C++来写。系统崩溃一次造成的损失，可能
比硬件的价格还贵。而一旦业务增长，用户数上升，面临的就是被迫重写
应用使其scalable，这要比硬件价格贵多了。
大多数行业 |
|
k***r
发帖数: 4260 | 14 Use case是这样的：
一个展览会场管理软件，希望有个直观的方法看到在某个位置的展位的信息，
还包括客户从一个图上选择展位并且预定，或者点击图上一个展位，update
information。后台数据库CRUD很简单，但是前台需要能够画一个示意图出来，
比较直观地从图上选择一个展位，做一些事情，比如预定，查询，等等。
一直没想好前面这个图要如何解决。基础可以用展览馆提供的扫描图。一个
问题是不同展览馆的图都不同，黑白彩色，摊位号全都不同，另一个问题，
也是更大的问题，是如何让用户在这个图上交互，比如预定展位，或者查询
某个展位信息。预定之后，展位应该显示已经预订，别人不能重复订。
问题之一：如何建model
后台要有一个model用来描述每个展览馆的图，展位位置，大小，价钱。如何
建立这个model就不容易，要一个一个小方块手工输入吗？比较痛苦。每次展览
布局可能都不同。另一个可能性就是从展览馆的图用OCR把区域和号码识别出
来，听上去工作量也不小。
问题之二：前段技术
可以用客户端软件，或者web based。用客户端软件，画这些小格子并且能
interact是可以做到的但是也不 |
|
g*****g
发帖数: 34805 | 15 Jee is good for mid-large scale projects that will last
several years for its life cycle. For simple CRUD project,
PHP and RoR will serve the quick and dirty purpose better. |
|
g*****g
发帖数: 34805 | 16 IDE可以很强大，比如Eclipse的jboss plugin可以从DB schema直接
产生一个CRUD的网站。类似这样的plugin很多。vim/emacs要想做一个
这样的extension，那就得吐血了。 |
|
g*****g
发帖数: 34805 | 17 It's not enough unless you want to be a pure swing or SWT developer.
And yes, a veteran JEE developer is supposed to master most of these
concepts. I'd suggest you focus on Spring, Hibernate and a simple
web framework (Stripes and Wicket are 2 simplest ones IMHO and spring
MVC is OK) to complete a simple CRUD project. You'll understand these
concepts once you are over that stage.
,
, |
|
h******b
发帖数: 6055 | 18 要么你像donwell那样亮出自己畅销榜上榜作品（打工仔做的不算），我马上佩服的五
体投地。
要么你跟我一样是0分。
什么叫骗？ js就是最强大的创业语言。 无论是web还是app通吃。 这年头无论是
web还是app有几个超越了基本的CRUD? 技术含量在我们business这边，对行业和数据
的理解，产品定位和设计。 选JavaScript是为了最快实现需求。
手游我没兴趣，你自己愿意在上面吊死随便。 |
|
h******b
发帖数: 6055 | 19 js无疑是效率最高学习成本最低的语言。 唯一一个web/app，前后台通吃的语言，最
适合我这种并非科班出身的。
产品成败是看产品定位，设计，和business model你难道不明白？ node的火就是因为
他能让你在初期最低成本过关。
那么多畅销榜成功app，有几个需要crud之上的功能的。 就拿donwell那个app来说，
在他用户数量爆棚之前，一样用过node。
至于能不能发财，我觉得突破个人瓶颈还是有可能的。 运气决定上限，个人努力决定
下限。 |
|
h******b
发帖数: 6055 | 20 要么你像donwell那样亮出自己畅销榜上榜作品（打工仔做的不算），我马上佩服的五
体投地。
要么你跟我一样是0分。
什么叫骗？ js就是最强大的创业语言。 无论是web还是app通吃。 这年头无论是
web还是app有几个超越了基本的CRUD? 技术含量在我们business这边，对行业和数据
的理解，产品定位和设计。 选JavaScript是为了最快实现需求。
手游我没兴趣，你自己愿意在上面吊死随便。 |
|
h******b
发帖数: 6055 | 21 js无疑是效率最高学习成本最低的语言。 唯一一个web/app，前后台通吃的语言，最
适合我这种并非科班出身的。
产品成败是看产品定位，设计，和business model你难道不明白？ node的火就是因为
他能让你在初期最低成本过关。
那么多畅销榜成功app，有几个需要crud之上的功能的。 就拿donwell那个app来说，
在他用户数量爆棚之前，一样用过node。
至于能不能发财，我觉得突破个人瓶颈还是有可能的。 运气决定上限，个人努力决定
下限。 |
|
f*********9
发帖数: 718 | 22 Entity Framework
Subsonic
CSLA
etc.
这些都可以做OR mapping
Entity Framework (4.0) 感觉最好, 如果在数据库里面把表, Prime key/Foreign key
都设计好了. CRUD/navigation 都很容易. |
|
z****e
发帖数: 54598 | 23 说的是web site
crud那些东西
如果你想做一些复杂的server
哦也，上java
顺便，但凡是脚本语言，对多线程并发的支持都不是很好
所以某些类脚本语言，在这一点上是比不过java的
倒是用scala有这个可能，不过我看scala写akka不会比java写akka简单多少
差不太多
route |
|
z****e
发帖数: 54598 | 24 groovy实现crud远比jython简单
还有就是，groovy的grails对于spring和hibernate的支持也远比你说的两个要好
好很多，而且这也正是groovy能够得到一部分市场的主因
你看，气急败坏是没有意义的，这个领域你不懂了吧
哈哈 |
|
z*******3
发帖数: 13709 | 25 来，大神我最喜欢看你点评了，你看我说的有没有道理
－－－－－－－－－－－－－－－－－－－－－－－－－
struts已经没有人用了
web server用什么都可以
无非是一个破server而已
而且web server开发会越来越简单
python之类的绝对不是终点，以后用xml来开发web server
客户端越来越复杂是大势所趋，但是进展灰常缓慢
等到统一的建模的tag出来，那可能都是二三十年以后的事情了
html5和css3很多很简单的tag都要等半天才出来
话说如果html和css做得好，js也没有多少事情可做
不管怎样，这些都只是理论，也许将来有一天
js可以进化到luna script的水平，然后通过定义img link
就可以自动实现2d动画，但是这一天还遥遥无期呢
政治斗争是最大的制肘，web是政治斗争最为激烈的地方
话说当年applet那么理想的一个模型，都硬生生地被搞死
不过如果那一天真的到来，做web开发的就准备下岗吧
那么简单的开发，工资不会高到哪里去
－－－－－－－－－－－－－－－－－－－－－－－－－－－
大神我们从来都没有鄙视web开发，只是觉得，web开发... 阅读全帖 |
|
g*****g
发帖数: 34805 | 26 I don't know about faster. If the application is simple CRUD, I bet PHP,
Python and Ruby can be faster. .Net does have a market, most from VB/VC
convert. As legacy apps are converted, its strength becomes a suspect. |
|
z*******3
发帖数: 13709 | 27 这种简单的crud的操作
应该优先想到各种脚本语言
比如python，groovy |
|
z****e
发帖数: 54598 | 28 python等类脚本的语言本身有很大问题
就是动态类型，这个在做大了之后优化时候，会有明显的缺陷
因为你不知道这个变量是什么类型，优化的工具就不敢去碰它
scala在开篇的时候，就特意强调，scala不是一个动态语言
另外一个被scala强化的就是，去掉了原始数据类型
保证所有的对象都真的是对象，在这两个基础之上
scala在特别大的环境下，就开始体现出其优势来
跟python更接近的是jvm上的groovy，所以groovy也就适合做一些crud的简单操作
无非都是那么点简单的动作，这里是列表
http://en.wikipedia.org/wiki/Dynamic_programming_language |
|
g*****g
发帖数: 34805 | 29 差在写复杂后端分层不行，类库少，不适合SOA架构。如果网站基本只是CRUD数据库，
当然够用了。 |
|
z*******3
发帖数: 13709 | 30 适合crud
不适合复杂的逻辑
实际上你说的scala也不适合复杂的逻辑
写出来压根不能看
复杂的逻辑还是上java
在可读性和生产效率上有一个平衡 |
|
z****e
发帖数: 54598 | 31 传统的http就是一个request过来，一个html的response回去
web service最早就是把request和response都封装成xml
然后还提出了service broker uddi和describer wsdl这两个xml
近乎疯狂滴使用了xml去封装和描述所有的东西
但是被证明过于复杂，以至于没有多少人真喜欢去用的
后来官方web service 2.0构架就简化了这一切，去掉了uddi，简化了wsdl
但是还是太heavy
坊间流传的是在http之上做的一点点扩展
就是restful web service，简单说就是一个request过来
一个xml的response回去，然后以前只有get/post两个http methods
被扩展成了四个methods，加了put和delete，这样就可以对应起crud操作
后来又有人提出把response和request都用json而不是xml来封装数据
这几个凑在一起，就形成今天常见的web service的主要形式
当然你还可以在这个基础之上继续扩展，随便改，这些都是web service
只要用web提供... 阅读全帖 |
|
n****1
发帖数: 1136 | 32 版上无数大佬声称OOP比FP更加符合人类的思维方式,俺个土鳖来唱个反调.
所有的程序,不管采用什么模式,架构, 其最终目的都是IO+persistence, 70%以上的应
用仅仅是CRUD外加个包装而已. 大多数应用的persistence是tabular database, 这包
括mysql这类ACID数据库, 也包括big table/cassandra这类的分布式数据库. 当然也有
OO database, 但普及率/接收度/性能都不如前者.
我们不妨回想在电脑诞生之前, 人类对一个复杂问题是如何建模与解决的.复杂问题千
奇百怪,比如生物学家要对物种进行门纲目科属种的划分, 这种划分能够体现各物种之
间的异同程度. 再举个例子,统计学家要做个人口普查,那就要建立个大表格,每一行都
对应一个人, 行中记录包括生日/性别/籍贯等等各种信息,这样我们从一个表里就可以
得到籍贯分布,人口年龄结构,地域与受教育程度的关联等等.
事实上在OOP普及以前,人类对事物种类的划分是有限的, 因为现实中存在的东西就那么
几样, 人们也不大需要过研究什么抽象物体. 可OOP发明后就不一样了, 程序... 阅读全帖 |
|
d***n
发帖数: 832 | 33 下面这句真不敢苟同。另外OO符合大部分人思维不觉得有什么好争议的。
--所有的程序,不管采用什么模式,架构, 其最终目的都是IO+persistence, 70%以上的应
用仅仅是CRUD外加个包装而已.
不过呢，这么瞎聊聊我觉得也挺有意思的，还是得鼓励一下 |
|
g*****g
发帖数: 34805 | 34 你走火入魔了，谁说对象需要独立人格？这个世界万物皆物体 (object)，物体需要独
立人格吗？
一个桌子没有任何思想，就不能有4条腿，一个面吗？你连最基本的常识都弄错了，还
推理了一大堆，I服了U。
事实上，OO里所谓对象，无非是一堆的相关的数据状态，用对象方法来确保数据的变化
保持一致性罢了。
另外，你对多线程的理解也很狭隘。actor model在复杂多线程的系统里很好用，可以
简化线程同步。
但反过来，如果系统并没有那么多的同步需要。比如绝大部分web应用，无非是某种形
式的CRUD，
有同步需要的部分都在数据库里处理了。这时候actor就如同spring bean里用
prototype，明明一个singleton够用了，却产生了大量的copy，导致GC开销提高很
多，造成性能下降。我个人用scala的时候为了最大化系统throughput，在调GC仍然有
问题之后，不得已用了object pool来重用actor，这已经违背了actor model的本意。
Erlang |
|
g*****g
发帖数: 34805 | 35 For green hands, I always recommend building a simple website that does CRUD,
e.g. User and group, using Spring MVC, Spring IoC and Hibernate. It probably
takes you a week to get it done an months to comprehend these technologies.
If you get that done, you've got 50% knowledge of being a qualified Java
developer and you can probably explore on your own from there. |
|
b***e
发帖数: 1419 | 36 Similar to the JQuery UI plugins, such rigid "UI frameworks" never work in
serious consumer facing products. It is probably only good for developing
CRUD based internal tools. Real real-world problems are usually coming with
much more complicated product requirements and much more involved user
interaction specifications than what such frameworks provide and suppport.
Instead of fighting such frameworks, it is better to build your own stuff
ground up with light weight lib support such as JQue... 阅读全帖 |
|
b***e
发帖数: 1419 | 37 Similar to the JQuery UI plugins, such rigid "UI frameworks" never work in
serious consumer facing products. It is probably only good for developing
CRUD based internal tools. Real real-world problems are usually coming with
much more complicated product requirements and much more involved user
interaction specifications than what such frameworks provide and suppport.
Instead of fighting such frameworks, it is better to build your own stuff
ground up with light weight lib support such as JQue... 阅读全帖 |
|
Y**G
发帖数: 1089 | 38 想像一下，你的 java 代码可以 subscribe dom 事件，而且可以对 dom tree 做 CRUD. |
|
n****1
发帖数: 1136 | 39 How many times do I need to repeat? DOM is not thread-safe! So it is a
single choice: you choose to manipulate the dom, you lost everything in JS!
Even google's native clients can not afford to do that, so they don't talk
to dom, instead passing/receiving messages to js runtime. It's basically
delegation pattern.
CRUD. |
|
g*****g
发帖数: 34805 | 40 嗯，上次那个无数个框架的benchmark，就是简单的CRUD，一堆框架秒了nodejs。 |
|
n****1
发帖数: 1136 | 41 你不就想说这帮做互联网的猴子不过在写CRUD的东西罢了, 我同意.
bug. |
|
c******3
发帖数: 296 | 42 单纯比代码量毫无意义，因为很多代码可以包在framework里。比如某个项目要求你把
数据库100个表发布到网上，对每个表作CRUD。你用Node会写几天几行？用Java有现成
的framework,一行代码都不用写。你Node再牛也比不过吧。 |
|
z****e
发帖数: 54598 | 43 来自主题: Programming版 - 简单就是美 你说设计db这个就是一个伪命题
我很早以前就把db简化成一个只懂crud的废物了
后来我发fb也在这么做
于是很自豪了一把，哈哈
db的逻辑应该剥离出来给java去写啊
现在搞nosql就是一个弱化的db咯，这么理解其实也没差多少
老姜你的知识体系是有点太老了 |
|
g*****g
发帖数: 34805 | 44 企业计算，即便今天，还是主要基于关系数据库的。你跟我装有用吗？还能改变现实不
成？
小企业，以前根本没能力起一个成百上千机器的数据中心，更遑论用这么多机器做数据
收集和处理，雇人做这个级别数据的处理应用。而今天就像MySQL上写个CRUD一样都成
为可能。 |
|
g*****g
发帖数: 34805 | 45 关于这个我反复说过。对于复杂多线程，java确实不如fp，如scala的actor好写。但另
一方面，绝大部分
应用的多线程都在框架部分里实现了，不需要开发者手工去写多线程。
想想大部分web应用是干啥的？无非就是多用户的crud罢了，有冲突的部分在数据库里
就解决了。
request和线程mapping部分在servlet解决了。有啥多线程要写？
事实上现在高并发，讲究的是stateless。state要嘛在客户前端，其余统统搬进数据库
，各种distributed Cache和NoSQL DB使得这种模式实现并不困难。集群节点完全相同
无状态，自然也不需要做什么同步，scale out, failover都很容易。我觉得这个才是
发展的方向。在需要锁的场合也是使用分布锁，如zookeeper.
parallelization
container. |
|
g*****g
发帖数: 34805 | 46 这东西可以简化开发，不可能替代。如果你只是CRUD，定义几个model object就有工具
能自动从前到后把整个网站生成，实际上有几个网站是这样的？ |
|
g*****g
发帖数: 34805 | 47 你要重现检视的是ORM这个词。O是躲不掉的，只要你用R，M就躲不掉。区别只在于
mapping是怎么实现的。ORM架构的主要目的是帮助你减少boiler plate代码，简化开发
。另一方面手写越多，灵活度越高，这是没有争议的。Spring jdbc也好，hibernate，
小轮子大轮子的区别，没有好坏的差异，区别在于使用的人。这两者本来就不是互斥的
，你大可以混合使用。JPA对于简单的关系很方便，Spring Data更是把这个做到了极致
，把缺省的CRUD都给你做了。当关系很复杂，比如你join了N个table还要group by的时
候，觉得spring jdbc template更方便很正常。
另一方面，当你觉得JPA不好用的时候，往往需要重新审视你的数据。最常见的原因是
因为速度的需要，为了减少join，大量denormalize。这是传统的做法，但不是唯一的
解决方案，往往不是最好的解决方案。如果纯粹为了减少join，可以考虑Elastic
Search，把整个object扔进去，而且搜索更强大。如果是表太大，不能忍受JPA产生的
query不是最优，也许Cassandr... 阅读全帖 |
|
