> And how this can't be achieved by Spring too? I just don't get the argument. > EntityManager can be injected.. No problemo.
I did not said it can not, i said spring approach will drag you to create anemic object. > And for user and password, if I would model it. Password property > would not be part of my User domain model. > There would be an UserAdmin service where #changeUserPassword( UserId, > String password ), and User will not have > #getPasssword() at all. Hence, for this use case to work for both > webbeans and spring, I would need to create a value object > to store the form values. Definitely you can create another object to maintain other object state, I do not oppose this approach or UserAdmin object, what I oppose is anemic domain object which can lead to procedural programming. If your UserAdmin is nothing but dumb object for stateless operation. Then you can be trapped into procedural programming. Which is normally happen in spring application. Why it happens? Because in spring and normal traditional web application, you need another java class to communicate with the framework. > > In regards to Manager, and Services. > There's nothing wrong with service. > For example, does transfer money from one account to another account > belong to domain model? > I would think you need to create a FundsTransferService as described > on page 72 in DDD book. > http://books.google.com.my/books?id=7dlaMs0SECsC&pg=PP4&source=gbs_selected_pages&cad=0_1 > Repositories, Services, Factory are all valid tools. Why not ?? I see it more elegant if the we have Bank object which has operation to transfer one account to another. Does it part of domain ? yes offcourse it is ! we can have several bank. Now bank is part of the domain. But why we have FundsTransferService at the first place ? the idea behind it, is to communicate with the framework ! see here we have a FundsTransferService, we open transaction, we close it, and we made the parameters as primitive as we can ? why ??? to comply it with the framework. To make us easy when we want to pass the parameters into this service object. And where we call the FundsTransferService, its in the controller, we get parameter from httpRequest, convert it, and pass it into our FundsTransferService. This approach definitely nothing wrong, it is nature for you to do that. You dont want to end up having domain which will parse httpRequest right ? It is the nature of stateless application. Todays webapplication development have shifted to broader concept. day by day people trying to make everything more simple,faster. Until at some point we found out that our web application actually does not need to be stateless. We can treat it as normal object which have state. > > Lastly controller. MVC is a valid design pattern. > There's nothing wrong with it. I don't argue with MVC here, aniwei who said webbeans/seams is not MVC :) Cheers
