On 18 oct, 09:29, agi <[email protected]> wrote: > Hallo, > > I would like to use RequestFactory mechanism as a way for retrival of > data from server. I have looked at the RequestFactory overwiev as well > as the expenses example and I have came up with some questions which > bother me.. > > I have already working project where I have DAO classes on the server > side, and entity(domain) classes also on the server side (previously > I've used Gilead to send entities to the client). My entities are pure > domain classes without any business logic and I would like to follow > this pattern.
I haven't yet updated my RequestFactory code to RC1 but I'll try to answer based on what I read (which includes design docs and GWT's internal code) See also, in case you haven't already read it: http://code.google.com/webtoolkit/doc/trunk/DevGuideRequestFactory.html > 1) What I see in the google expenses example is that the Enitity class > is holding not only data model but also business logic, also as far as > I've understood any Entity must have findEntity( Long|String id) , > which is business method. > > -Why it is designed like this? Is this the correct way to design > application to put data model and business logic together? When you don't have much business logic (CRUD, as in the Expenses sample), you don't need to separate out a "service" layer. Some also consider "service layers" (or rather, "anemic domain models") a bad design: http://martinfowler.com/bliki/AnemicDomainModel.html > Can I put it separately? You can separate them: - business logic in your "requests" interfaces and their @Service server classes counterparts - data model in EntityProxy interfaces and their @ProxyFor server classes counterparts Though there are shortcomings in the RC1 release; which includes the findXxx static method on your entities (data model). I've heard this will be sorted out in a 2.1.1 release shortly after the 2.1.0. FYI, the separation wasn't in the original design of RequestFactory, where entities really did have to contain the business logic. > 2) I have tried to use my DAO classes as parameter for RequestContext > class like > @Service(MyEntityDao.class) > public interface EntityRequest extends RequestContext > > I have also problems with persist() and remove() methods which should > return InstanceRequest<EntityProxy, eventual_return_type> persist(); > when implemented those methods in my dao I have gw-compiler error: > [ERROR] Parameter 0 of method EntityRequest.persist does not match > methodMyEntityDao.persist This is a known issue: https://jira.springsource.org/browse/ROO-1499 > -Are those methods allowed outside Etnity class? can I implement them > in my Dao classes? The persist() and remove() methods from the Expenses sample and the documentation have nothing special (it wasn't the case in previous milestones of 2.1, and that's probably why they're still instance methods on the entities). You're not forced to use instance methods, you can very well use "service methods" (static methods on your @Service class) passing the entity as an argument. And you can use any kind of instance method (not only persist() and remove()) on the client side by returning an InstanceRequest instead of Request. > Thanks in advance for any responce:) I just hope I'm right in my answers ;-) -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
