z*******3
发帖数: 13709 | 1 service还是dao/repository？ |
g*****g
发帖数: 34805 | 2 Of course you do it in service. So you make decision whether to rollback
with certain exception, whether to combine multiple writes into one
transaction etc. How else can you do it when you operate multiple DAOs?
Keep dao simple and dumb. The way I like to think what DAO should be is:
If you have to change to another DB, with a very different implementation (
JDBC, iBatis you name it). Can you not alter your service, and still
minimize the code you have to write on new DAO.
【在 z*******3 的大作中提到】
: service还是dao/repository？
|
t*******e
发帖数: 684 | 3 应该问从哪一层开始transaction. 从web就可以开始了。 |
z*******3
发帖数: 13709 | 4 我也是觉得在service做比较合理
但是在service做，spring用aop来作，ejb容器用显式的transaction标记来做
appengine的objectify就没有办法了，除非加上guice的aop
那样就大了，就慢了，所以我现在只能做在dao里面
从web就开始做，有点太过于早了点
毕竟action跟service很可能是在不同物理机器上的
这样跨机器搞transaction是忌讳，还是不要了 |
w**z
发帖数: 8232 | 5 nosql, 不用transaction, 幸福啊。
【在 z*******3 的大作中提到】
: service还是dao/repository？
|
w**z
发帖数: 8232 | 6 from my previous job, we start transaction in service layer.
【在 g*****g 的大作中提到】
: Of course you do it in service. So you make decision whether to rollback
: with certain exception, whether to combine multiple writes into one
: transaction etc. How else can you do it when you operate multiple DAOs?
: Keep dao simple and dumb. The way I like to think what DAO should be is:
: If you have to change to another DB, with a very different implementation (
: JDBC, iBatis you name it). Can you not alter your service, and still
: minimize the code you have to write on new DAO.
|
s*******e
发帖数: 3042 | 7 感觉db transparent对绝大多数公司来说只有理论上的好处，好多年前，我们的还把这
个作为要求之一，现在发现，在一个大公司，换DB的可能性太小了，与其在上面投入精
力，不如根本不考虑，等到真正换的时候再说。
【在 g*****g 的大作中提到】
: Of course you do it in service. So you make decision whether to rollback
: with certain exception, whether to combine multiple writes into one
: transaction etc. How else can you do it when you operate multiple DAOs?
: Keep dao simple and dumb. The way I like to think what DAO should be is:
: If you have to change to another DB, with a very different implementation (
: JDBC, iBatis you name it). Can you not alter your service, and still
: minimize the code you have to write on new DAO.
|
z*******3
发帖数: 13709 | 8 然后每次都call store procedure？
【在 s*******e 的大作中提到】
: 感觉db transparent对绝大多数公司来说只有理论上的好处，好多年前，我们的还把这
: 个作为要求之一，现在发现，在一个大公司，换DB的可能性太小了，与其在上面投入精
: 力，不如根本不考虑，等到真正换的时候再说。
|
g*****g
发帖数: 34805 | 9 db transparency是其次。关键在于清晰的分层有助于写好维护的代码。
好的层次只会使得代码量减少，不会更多。
【在 s*******e 的大作中提到】
: 感觉db transparent对绝大多数公司来说只有理论上的好处，好多年前，我们的还把这
: 个作为要求之一，现在发现，在一个大公司，换DB的可能性太小了，与其在上面投入精
: 力，不如根本不考虑，等到真正换的时候再说。
|
o***i
发帖数: 603 | 10 同意！
【在 s*******e 的大作中提到】
: 感觉db transparent对绝大多数公司来说只有理论上的好处，好多年前，我们的还把这
: 个作为要求之一，现在发现，在一个大公司，换DB的可能性太小了，与其在上面投入精
: 力，不如根本不考虑，等到真正换的时候再说。
|
|
|
o***i
发帖数: 603 | 11 我觉得所谓好的层次其实很大程度上要看项目的规模的
小项目如果层次搞得太复杂，去套用所谓“好的层次”只会增加代码量，降低可读性
【在 g*****g 的大作中提到】
: db transparency是其次。关键在于清晰的分层有助于写好维护的代码。
: 好的层次只会使得代码量减少，不会更多。
|
g*****g
发帖数: 34805 | 12 看你项目有多小了，写完就可以扔掉是不需要。业界的框架和工具都是根据这些分层的
理念
来设计的，为的是好的可扩展性和可维护性。即便显得繁琐，也可以使日后的维护变得
简单。
以spring+hibernate为代表的中后层，现在并没有明显的冗余代码。事实上一个
annotation就可以标明transaction，不能再简单了。这要比写JDBC容易多了。
如果项目非常简单，可以考虑的是用Spring Roo之类的工具直接把大部分代码生成了。
【在 o***i 的大作中提到】
: 我觉得所谓好的层次其实很大程度上要看项目的规模的
: 小项目如果层次搞得太复杂，去套用所谓“好的层次”只会增加代码量，降低可读性
|
o***i
发帖数: 603 | 13 想体验一把hibernate今天去和头说能不能在我负责的project里用hibernate结果被秒据
了。。。
【在 g*****g 的大作中提到】
: 看你项目有多小了，写完就可以扔掉是不需要。业界的框架和工具都是根据这些分层的
: 理念
: 来设计的，为的是好的可扩展性和可维护性。即便显得繁琐，也可以使日后的维护变得
: 简单。
: 以spring+hibernate为代表的中后层，现在并没有明显的冗余代码。事实上一个
: annotation就可以标明transaction，不能再简单了。这要比写JDBC容易多了。
: 如果项目非常简单，可以考虑的是用Spring Roo之类的工具直接把大部分代码生成了。
|
z*******3
发帖数: 13709 | 14 系统是会成长的
很少系统说一直就那么点量
谁都希望系统越做越大
说明生意越来越大
系统越做越小那不是破产了
前面偷工减料，后面是要还回去的
【在 o***i 的大作中提到】
: 我觉得所谓好的层次其实很大程度上要看项目的规模的
: 小项目如果层次搞得太复杂，去套用所谓“好的层次”只会增加代码量，降低可读性
|
b******y
发帖数: 9224 | 15
俗话说的好，出来混，总是要还回去的 ^_^
【在 z*******3 的大作中提到】
: 系统是会成长的
: 很少系统说一直就那么点量
: 谁都希望系统越做越大
: 说明生意越来越大
: 系统越做越小那不是破产了
: 前面偷工减料，后面是要还回去的
|
n*w
发帖数: 3393 | 16 Why? Or your team is using another orm?
秒据
【在 o***i 的大作中提到】
: 想体验一把hibernate今天去和头说能不能在我负责的project里用hibernate结果被秒据
: 了。。。
|
c*********e
发帖数: 16335 | 17 service.
我一般做个servicelocator,然后servlet就用servicelocator里面的static method.
这些static method就是做crud
【在 z*******3 的大作中提到】
: service还是dao/repository？
|
c*********e
发帖数: 16335 | 18 那个时候，可能人都跳槽发大财去了。
【在 z*******3 的大作中提到】
: 系统是会成长的
: 很少系统说一直就那么点量
: 谁都希望系统越做越大
: 说明生意越来越大
: 系统越做越小那不是破产了
: 前面偷工减料，后面是要还回去的
|
z****e
发帖数: 54598 | 19 你跳槽多了你就知道
其实真正发财的是那些不怎么跳槽的
【在 c*********e 的大作中提到】
: 那个时候，可能人都跳槽发大财去了。
|
c*********e
发帖数: 16335 | 20 不跳槽怎么涨工资？
【在 z****e 的大作中提到】
: 你跳槽多了你就知道
: 其实真正发财的是那些不怎么跳槽的
|
|
|
z****e
发帖数: 54598 | 21 跳槽可以短期内迅速涨工资
但是一旦到了一个数量
再往上就不是那么容易靠跳槽涨了
相反，用资历来涨的多
你们公司不可能每年都不加薪吧？
【在 c*********e 的大作中提到】
: 不跳槽怎么涨工资？
|
c*********e
发帖数: 16335 | 22 很多公司，title升了也不涨工资。
跳槽跳个几次，等工资到了中上等，就不跳了。
【在 z****e 的大作中提到】
: 跳槽可以短期内迅速涨工资
: 但是一旦到了一个数量
: 再往上就不是那么容易靠跳槽涨了
: 相反，用资历来涨的多
: 你们公司不可能每年都不加薪吧？
|
z****e
发帖数: 54598 | 23 熬吧，熬出资历来就可以混上去了
不过我看我领导天天忙得一塌糊涂的
我们这边很搞笑
做领导的忙死，下面一堆人经常不来
一般一个10个人的team，每天都有人请假
每天都能收到邮件，＊＊＊今天干嘛干嘛，不来了
然后领导累得半死，假期用不完，也没有机会用
所以他们是领导
【在 c*********e 的大作中提到】
: 很多公司，title升了也不涨工资。
: 跳槽跳个几次，等工资到了中上等，就不跳了。
|
c*********e
发帖数: 16335 | 24 所以很多人即使干tech leader,也不做manager.manager失业了难找工作。
【在 z****e 的大作中提到】
: 熬吧，熬出资历来就可以混上去了
: 不过我看我领导天天忙得一塌糊涂的
: 我们这边很搞笑
: 做领导的忙死，下面一堆人经常不来
: 一般一个10个人的team，每天都有人请假
: 每天都能收到邮件，＊＊＊今天干嘛干嘛，不来了
: 然后领导累得半死，假期用不完，也没有机会用
: 所以他们是领导
|
o***i
发帖数: 603 | 25 码工没原始股怎么都不会发财呀
【在 z****e 的大作中提到】
: 你跳槽多了你就知道
: 其实真正发财的是那些不怎么跳槽的
|
z****e
发帖数: 54598 | 26 赌博而已
拿自己的前途去赌博
startup倒掉的不要太多
【在 o***i 的大作中提到】
: 码工没原始股怎么都不会发财呀
|
