Print Page | Close Window

Why only a single nested WsQuery per Entity?

Printed From: IdeaBlade
Category: DevForce
Forum Name: DevForce Classic
Forum Discription: For .NET 2.0
URL: http://www.ideablade.com/forum/forum_posts.asp?TID=291
Printed Date: 30-Aug-2025 at 1:37am


Topic: Why only a single nested WsQuery per Entity?
Posted By: Customer
Subject: Why only a single nested WsQuery per Entity?
Date Posted: 16-Jul-2007 at 2:29pm

My question is with the ObjectMapper tool mapped to a WSDL file (WebService).

 

 

Let's say forexample that we have an OrderService with methods:

 

findOrdersByCustomer(FindByCustomerRequest)

findOrdersBySalesRepresentative(FindBySalesRepresentativeRequest)

findCustomerByOrder(FindByOrderRequest)

 

With the "Add Unmapped Web Service Methods" tool I can select all methods, but only 1 method is allowed for each "Base" entity at the time?

 

That is, the tool generates

 

the Orders class has a WsQuery with a constructor for FindByCustomerRequest

the Customer class has a WsQuery with a constructor for FindByOrderRequest

 

I would expect the Orders class to also have a WsQuery for the second findOrdersBySalesRepresentative method. It seems that the tool always selects the FIRST checked method in the list, then discards all other selected methods with the equal return value.




Replies:
Posted By: IdeaBlade
Date Posted: 16-Jul-2007 at 2:30pm

The problem is due to a known limitation.  We allow for only a single WsQuery nested class to be created within an Entity class, so the first checked method will be the only method created.  The use of only a single nested WsQuery per Entity was intentional, and follows our implementation of stored procedure backed entities.  The good news is that these nested classes are really just helper classes defined to make constructing a WsQuery easier, and are not required to be used.

 There are a couple workarounds to look at:

 1) Since the *DataRow classes are partial, you can write your own additional WsQueryX nested class, using the existing class as a template so that you only need to change the parameter and execute information.  You don’t need to make the class nested if you prefer not to, since the nesting is just a convenience not a requirement.

 2) Call the base IdeaBlade.Persistence.WS.WsQuery class directly.  Here again you can consult an existing nested class to see how it constructs the base WsQuery.  Getting the constructor right is the primary difficulty here.  You’ll want to use either:

public WsQuery(String pServiceName, String pMethodName, Type pEntityType, WsProxyType pProxyType) or

public WsQuery(Type pClientProxyType, String pMethodName, Type pEntityType)  - preferred

 

 




Print Page | Close Window