hi guys, i'm wondering if llblgen pro support direct sql query instead of converting it into predicate? thanks

Not directly. What kind of query do you want to execute? You can probably convert it to predicates easily or use one of the mechanisms to execute a delete/update directly on the db.

like my past experience with hibernate, it support few flavours when come to data accessing. object search, hibernate query language and the expression method. so i want to find out if llblgen pro do have its own query language aside from predicate method.

btw, i also having problem when using llblgen pro data object in web service. due to the serialization, all EntityCollection will be converted to dataset and send to the client. is there any workaround so that the entity and collection will actually pass thru the web proxy to the client as it is? or my only choice were to be the .net remoting?

jump_912 wrote:

like my past experience with hibernate, it support few flavours when come to data accessing. object search, hibernate query language and the expression method. so i want to find out if llblgen pro do have its own query language aside from predicate method.

That IS LLBLGenPro's language . It uses a typed system to form filters (predicate expressions and relation collections, as a WHERE clause is an expression of predicates for example), not a string based system ala hibernate which breaks at runtime when a name changes instead of at compile time.

btw, i also having problem when using llblgen pro data object in web service. due to the serialization, all EntityCollection will be converted to dataset and send to the client. is there any workaround so that the entity and collection will actually pass thru the web proxy to the client as it is? or my only choice were to be the .net remoting?

That's indeed an issue, the only option you have is what MS tells everyone to do: alter the generated proxy classes . Though you can also opt for a true message format and create these in your code, for example based ona contract-first policy. That's more preferable than passing around XML which are directly produced from objects or datasets. True messages are more SOA and the preferred way to do SOA. (MS is also aware of that now thankfully).

If you're writing the client and the server, remoting is preferred, as it's easier for you to work with.

Otis wrote:

Though you can also opt for a true message format and create these in your code, for example based ona contract-first policy. That's more preferable than passing around XML which are directly produced from objects or datasets. True messages are more SOA and the preferred way to do SOA. (MS is also aware of that now thankfully).

Frans,

Just a thought... do you think the generator could be extended to generate a lightweight XSD Schema for entities. Not the full serialization structure, but a light version including selected fields only (including related entities). Generated entity classes could then also perform a lightweight serialize / deserialize matching the target schema...

I was considering writing a custom template to do this, but there was a problem concerning the fact that I would have to generate all fields rather than "selected fields". The generator is really the place to be able to select if a field is to be included in the schema or not... These low level schemas would be very useful to incorporate into WSDL, as most of the time the database table is very close to the DTO schema anyway... I know you would then loose the remote functionality you currently have with serialization, but in SOA this functionality would likely not not be used anyway...

I know you don't like SOA, but the reality is that people are starting to do it... It might give the product another edge...

Marcus

Well, I don't like the hype around SOA I do realize that a proper message format which is defined to be the format for messaging is great and should be supported above serializing graphs of objects or datasets.

Which is what I'll investigate for 2.0: XmlAccessAdapter , which should do object to document mapping, if possible