Re: OT: How to connect Wicket layer to underlying service layer
Me too, it's not easy to find these books in Brazil, I will try to buy a electronic copy of it. On Tue, Mar 24, 2009 at 2:40 PM, James Carman wrote: > On Tue, Mar 24, 2009 at 12:53 PM, Dave Schoorl wrote: >> >> Maybe Eric Evans Book 'Domain-Driven Design'? > > Yep, that's the one I would suggest. Although, I am going to check > out Fowler's book too. That's one I don't have yet! :) > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > > - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: OT: How to connect Wicket layer to underlying service layer
On Tue, Mar 24, 2009 at 12:53 PM, Dave Schoorl wrote: > > Maybe Eric Evans Book 'Domain-Driven Design'? Yep, that's the one I would suggest. Although, I am going to check out Fowler's book too. That's one I don't have yet! :) - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: OT: How to connect Wicket layer to underlying service layer
Maybe Eric Evans Book 'Domain-Driven Design'? Kaspar Fischer wrote: James, Eduardo, Jeremy, thank you very much for your input! I follow your discussions with great interest. Can you recommend a book on this sort of questions? I have read books on Spring and Hibernate but not from this high-level point of view. Cheers, Kaspar On 24.03.2009, at 17:38, Eduardo Nunes wrote: Ok I got it. One question, consider that you have this model: Person 1xN Address You have a screen that list a detailed view of a person, including a list of addresses. What approach do you use to implement it? - A service method that returns a Person entity with eager load of the list of Addresses? (if you don't need always the addresses this doesn't make sense) - A service method that returns a Person entity with lazy load of the list of Addresses? (it could be a problem in a JEE environment) - Two service methods, one to return the Person entity and another one to return the of addresses? Thanks, Eduardo S. Nunes On Tue, Mar 24, 2009 at 1:11 PM, Jeremy Thomerson wrote: Agree again. -- Jeremy Thomerson http://www.wickettraining.com On Tue, Mar 24, 2009 at 11:11 AM, James Carman wrote: On Tue, Mar 24, 2009 at 12:08 PM, Eduardo Nunes wrote: Yes, I understand you too. What do you do when you have to send a set of entities and a calculation for each entity? you encapsulate it inside another class? A domain-driven design advocate would say that the entity knows how to calculate what you need and you can ask it for the calculated value. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: OT: How to connect Wicket layer to underlying service layer
Kaspar, Flick through Martin Fowler's "Patterns of Enterprise Application Architecture" to see if you like it. Regards - Cemal http://jWeekend.com jWeekend hbf wrote: > > James, Eduardo, Jeremy, thank you very much for your input! > > I follow your discussions with great interest. > > Can you recommend a book on this sort of questions? I have read books > on Spring and Hibernate but not from this high-level point of view. > > Cheers, > Kaspar > > > On 24.03.2009, at 17:38, Eduardo Nunes wrote: > >> Ok I got it. One question, consider that you have this model: >> >> Person 1xN Address >> >> You have a screen that list a detailed view of a person, including a >> list of addresses. What approach do you use to implement it? >> - A service method that returns a Person entity with eager load of the >> list of Addresses? (if you don't need always the addresses this >> doesn't make sense) >> - A service method that returns a Person entity with lazy load of the >> list of Addresses? (it could be a problem in a JEE environment) >> - Two service methods, one to return the Person entity and another one >> to return the of addresses? >> >> Thanks, >> Eduardo S. Nunes >> >> On Tue, Mar 24, 2009 at 1:11 PM, Jeremy Thomerson >> wrote: >>> Agree again. >>> >>> -- >>> Jeremy Thomerson >>> http://www.wickettraining.com >>> >>> >>> >>> On Tue, Mar 24, 2009 at 11:11 AM, James Carman >>> >>> wrote: >>> On Tue, Mar 24, 2009 at 12:08 PM, Eduardo Nunes wrote: > Yes, I understand you too. What do you do when you have to send a > set > of entities and a calculation for each entity? you encapsulate it > inside another class? A domain-driven design advocate would say that the entity knows how to calculate what you need and you can ask it for the calculated value. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org >>> >> >> - >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >> For additional commands, e-mail: users-h...@wicket.apache.org >> > > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > > > -- View this message in context: http://www.nabble.com/OT%3A-How-to-connect-Wicket-layer-to-underlying-service-layer-tp22683138p22684726.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: OT: How to connect Wicket layer to underlying service layer
James, Eduardo, Jeremy, thank you very much for your input! I follow your discussions with great interest. Can you recommend a book on this sort of questions? I have read books on Spring and Hibernate but not from this high-level point of view. Cheers, Kaspar On 24.03.2009, at 17:38, Eduardo Nunes wrote: Ok I got it. One question, consider that you have this model: Person 1xN Address You have a screen that list a detailed view of a person, including a list of addresses. What approach do you use to implement it? - A service method that returns a Person entity with eager load of the list of Addresses? (if you don't need always the addresses this doesn't make sense) - A service method that returns a Person entity with lazy load of the list of Addresses? (it could be a problem in a JEE environment) - Two service methods, one to return the Person entity and another one to return the of addresses? Thanks, Eduardo S. Nunes On Tue, Mar 24, 2009 at 1:11 PM, Jeremy Thomerson wrote: Agree again. -- Jeremy Thomerson http://www.wickettraining.com On Tue, Mar 24, 2009 at 11:11 AM, James Carman wrote: On Tue, Mar 24, 2009 at 12:08 PM, Eduardo Nunes wrote: Yes, I understand you too. What do you do when you have to send a set of entities and a calculation for each entity? you encapsulate it inside another class? A domain-driven design advocate would say that the entity knows how to calculate what you need and you can ask it for the calculated value. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: OT: How to connect Wicket layer to underlying service layer
Ok I got it. One question, consider that you have this model: Person 1xN Address You have a screen that list a detailed view of a person, including a list of addresses. What approach do you use to implement it? - A service method that returns a Person entity with eager load of the list of Addresses? (if you don't need always the addresses this doesn't make sense) - A service method that returns a Person entity with lazy load of the list of Addresses? (it could be a problem in a JEE environment) - Two service methods, one to return the Person entity and another one to return the of addresses? Thanks, Eduardo S. Nunes On Tue, Mar 24, 2009 at 1:11 PM, Jeremy Thomerson wrote: > Agree again. > > -- > Jeremy Thomerson > http://www.wickettraining.com > > > > On Tue, Mar 24, 2009 at 11:11 AM, James Carman > wrote: > >> On Tue, Mar 24, 2009 at 12:08 PM, Eduardo Nunes wrote: >> > Yes, I understand you too. What do you do when you have to send a set >> > of entities and a calculation for each entity? you encapsulate it >> > inside another class? >> >> A domain-driven design advocate would say that the entity knows how to >> calculate what you need and you can ask it for the calculated value. >> >> - >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >> For additional commands, e-mail: users-h...@wicket.apache.org >> >> > - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: OT: How to connect Wicket layer to underlying service layer
Agree again. -- Jeremy Thomerson http://www.wickettraining.com On Tue, Mar 24, 2009 at 11:11 AM, James Carman wrote: > On Tue, Mar 24, 2009 at 12:08 PM, Eduardo Nunes wrote: > > Yes, I understand you too. What do you do when you have to send a set > > of entities and a calculation for each entity? you encapsulate it > > inside another class? > > A domain-driven design advocate would say that the entity knows how to > calculate what you need and you can ask it for the calculated value. > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > >
Re: OT: How to connect Wicket layer to underlying service layer
On Tue, Mar 24, 2009 at 12:08 PM, Eduardo Nunes wrote: > Yes, I understand you too. What do you do when you have to send a set > of entities and a calculation for each entity? you encapsulate it > inside another class? A domain-driven design advocate would say that the entity knows how to calculate what you need and you can ask it for the calculated value. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: OT: How to connect Wicket layer to underlying service layer
Yes, I understand you too. What do you do when you have to send a set of entities and a calculation for each entity? you encapsulate it inside another class? On Tue, Mar 24, 2009 at 1:02 PM, James Carman wrote: > On Tue, Mar 24, 2009 at 11:56 AM, Eduardo Nunes wrote: >> >> I always use DTO in service methods. My point of view is that if you >> have a method named "getSimpleUserList" and your User entity has 10 >> attributes and for this simple list you just need 3 of them, doesn't >> make sense to me return a Set of User objects, for that I would create >> a SimpleUserDto and return a Set of it. > > I'm not a big fan of DTOs. I understand why folks use them, but until > I figure out that I actually need them (for performance reasons), I > actually stick with just sending back my entities from the database. > For the most part, it works for me and I find it convenient to have > everyone coding to the same "domain" objects. > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > > - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: OT: How to connect Wicket layer to underlying service layer
I agree wholeheartedly with both of James' points. Put it all in the same webapp until you are absolutely certain that you've outgrown that. And I don't like DTO's. Why is it "better" to return an object that only has three fields when you don't need all ten? Doesn't this imply that you've broken the separation of concerns - your service layer is coded to know what fields your view layer needs? Also, why have duplicate objects to have to maintain? And what would returning the extra fields hurt? Anyway, just my two cents. -- Jeremy Thomerson http://www.wickettraining.com On Tue, Mar 24, 2009 at 11:02 AM, James Carman wrote: > On Tue, Mar 24, 2009 at 11:56 AM, Eduardo Nunes wrote: > > > > I always use DTO in service methods. My point of view is that if you > > have a method named "getSimpleUserList" and your User entity has 10 > > attributes and for this simple list you just need 3 of them, doesn't > > make sense to me return a Set of User objects, for that I would create > > a SimpleUserDto and return a Set of it. > > I'm not a big fan of DTOs. I understand why folks use them, but until > I figure out that I actually need them (for performance reasons), I > actually stick with just sending back my entities from the database. > For the most part, it works for me and I find it convenient to have > everyone coding to the same "domain" objects. > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > >
Re: OT: How to connect Wicket layer to underlying service layer
On Tue, Mar 24, 2009 at 11:56 AM, Eduardo Nunes wrote: > > I always use DTO in service methods. My point of view is that if you > have a method named "getSimpleUserList" and your User entity has 10 > attributes and for this simple list you just need 3 of them, doesn't > make sense to me return a Set of User objects, for that I would create > a SimpleUserDto and return a Set of it. I'm not a big fan of DTOs. I understand why folks use them, but until I figure out that I actually need them (for performance reasons), I actually stick with just sending back my entities from the database. For the most part, it works for me and I find it convenient to have everyone coding to the same "domain" objects. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: OT: How to connect Wicket layer to underlying service layer
Yes, I suggest to you the same approach. Put everything in the same webapp, just take care to separate the tiers. For example: don't modify inside a service method the method parameters because it won't work in a EJB for example. I used to build a huge environment n-tier with different jar files for each tier, beautiful from the architecture view, but expensive to develop, and sometimes you don't need this huge approach. My advice is, do it simple but taking care to handle evolution, to in the future put it a cluster, ejbs, jms, etc. The architecture that I use is: Wicket in front end, components calling service methods. Service methods using JPA/Hibernate and now I will use Warp-persistent Dynamic Filters to act as a DAO. I always use DTO in service methods. My point of view is that if you have a method named "getSimpleUserList" and your User entity has 10 attributes and for this simple list you just need 3 of them, doesn't make sense to me return a Set of User objects, for that I would create a SimpleUserDto and return a Set of it. Please, if I was confuse, ask me more, my english isn't perfect. Thanks On Tue, Mar 24, 2009 at 12:41 PM, James Carman wrote: > Put your services in the same webapp. > > On Tue, Mar 24, 2009 at 11:37 AM, Kaspar Fischer wrote: >> I am trying to figure out the architecture of a prototype application. In >> it, the presentation layer (Wicket) needs to work with a service layer to >> display and edit lists (among other things). The service layer also exposes >> some Web Services via SOAP/REST which I intend to use for a Flash/Flex >> component that will be on the pages served by Wicket and will display the >> lists in a graphical and interactive way. >> >> What options do I have to connect the presentation and middle layer? >> >> - RMI between Wicket and the service layer: This would allow them to run >> separately (e.g., we can work on the presentation without taking down the >> service layer who is running background processes). >> >> - Service layer and Wicket in the same webapp. >> >> - Service layer and Wicket in separate webapps but with Tomcat's >> crossContext set to true. >> >> - Anything else? >> >> Can anybody share some recommendations or experiences? >> >> I am worried that RMI will not only be a performance bottleneck (is it?) but >> also that it will be hard to work with models. Looking at wicket-phonebook, >> >> https://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/trunk/wicketstuff-core/phonebook/src/main/java/wicket/contrib/phonebook/web/DetachableContactModel.java >> >> I see that the presentation layer has access to the DAO and stores id's in >> its models. With an RMI separation, the DAO is in the middle layer and not >> accessible from the presentation layer. Also, transactional boundaries are >> in the service layer, so I will not be able to do something "more complex" >> in the presentation layer (which I shouldn't do anyway, I guess). >> >> Many thanks for feedback, >> Kaspar >> >> - >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >> For additional commands, e-mail: users-h...@wicket.apache.org >> >> > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > > - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: OT: How to connect Wicket layer to underlying service layer
Put your services in the same webapp. On Tue, Mar 24, 2009 at 11:37 AM, Kaspar Fischer wrote: > I am trying to figure out the architecture of a prototype application. In > it, the presentation layer (Wicket) needs to work with a service layer to > display and edit lists (among other things). The service layer also exposes > some Web Services via SOAP/REST which I intend to use for a Flash/Flex > component that will be on the pages served by Wicket and will display the > lists in a graphical and interactive way. > > What options do I have to connect the presentation and middle layer? > > - RMI between Wicket and the service layer: This would allow them to run > separately (e.g., we can work on the presentation without taking down the > service layer who is running background processes). > > - Service layer and Wicket in the same webapp. > > - Service layer and Wicket in separate webapps but with Tomcat's > crossContext set to true. > > - Anything else? > > Can anybody share some recommendations or experiences? > > I am worried that RMI will not only be a performance bottleneck (is it?) but > also that it will be hard to work with models. Looking at wicket-phonebook, > > https://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/trunk/wicketstuff-core/phonebook/src/main/java/wicket/contrib/phonebook/web/DetachableContactModel.java > > I see that the presentation layer has access to the DAO and stores id's in > its models. With an RMI separation, the DAO is in the middle layer and not > accessible from the presentation layer. Also, transactional boundaries are > in the service layer, so I will not be able to do something "more complex" > in the presentation layer (which I shouldn't do anyway, I guess). > > Many thanks for feedback, > Kaspar > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > > - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
OT: How to connect Wicket layer to underlying service layer
I am trying to figure out the architecture of a prototype application. In it, the presentation layer (Wicket) needs to work with a service layer to display and edit lists (among other things). The service layer also exposes some Web Services via SOAP/REST which I intend to use for a Flash/Flex component that will be on the pages served by Wicket and will display the lists in a graphical and interactive way. What options do I have to connect the presentation and middle layer? - RMI between Wicket and the service layer: This would allow them to run separately (e.g., we can work on the presentation without taking down the service layer who is running background processes). - Service layer and Wicket in the same webapp. - Service layer and Wicket in separate webapps but with Tomcat's crossContext set to true. - Anything else? Can anybody share some recommendations or experiences? I am worried that RMI will not only be a performance bottleneck (is it?) but also that it will be hard to work with models. Looking at wicket-phonebook, https://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/trunk/wicketstuff-core/phonebook/src/main/java/wicket/contrib/phonebook/web/DetachableContactModel.java I see that the presentation layer has access to the DAO and stores id's in its models. With an RMI separation, the DAO is in the middle layer and not accessible from the presentation layer. Also, transactional boundaries are in the service layer, so I will not be able to do something "more complex" in the presentation layer (which I shouldn't do anyway, I guess). Many thanks for feedback, Kaspar - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
