Hi, is there anything in LLBLGen similar to the Update() method of an ADO.NET SqlDataAdapter?

We think about using an O/R mapper but we also think about how we can synchronize changes in offline scenarios where a user disconnects from a server and later reconnects and replicates his data.

The Update() method automatically reconizes which record is new, changed, deleted. But when using LLBLGen, we would have to recode this behaviour using events or triggers, right?

Thus, does it still pay to use a tool like LLBLGen when offline scenarios must be supported?

Best Regards, Mario

mario.muja wrote:

Hi, is there anything in LLBLGen similar to the Update() method of an ADO.NET SqlDataAdapter?

We think about using an O/R mapper but we also think about how we can synchronize changes in offline scenarios where a user disconnects from a server and later reconnects and replicates his data.

The Update() method automatically reconizes which record is new, changed, deleted. But when using LLBLGen, we would have to recode this behaviour using events or triggers, right?

No, you don't have to do that Entities track their own changes. So you can just load some entities, send them to a remoted client, there they're modified, and when they come back you just save them.

You can also use a UnitOfWork object, which is serializable, to which you can add entities to be deleted as well. You then send the UnitOfWork to the server and commit it. All actions recorded with that unitofwork object are then executed in a transaction.

Otis wrote:

No, you don't have to do that Entities track their own changes. So you can just load some entities, send them to a remoted client, there they're modified, and when they come back you just save them.

How does the client remember the changes when the user closes the application and later reconnects to transfer his changes? That's a step between your "they're modified" and "when they come back". We think about the client having it's own database, which the client works on until the connection to the server is reestablished.

Otis wrote:

You can also use a UnitOfWork object, which is serializable, to which you can add entities to be deleted as well. You then send the UnitOfWork to the server and commit it. All actions recorded with that unitofwork object are then executed in a transaction.

Why should we add entities to be deleted to such a UnitOfWork? What is so special about deletion (why did you mention this)? Are deletion markers only supported for this UnitOfWork stuff or is it generally possible to mark an object as deleted in a similar way as a row becomes marked as deleted in a DataTable?

mario.muja wrote:

Otis wrote:

No, you don't have to do that Entities track their own changes. So you can just load some entities, send them to a remoted client, there they're modified, and when they come back you just save them.

How does the client remember the changes when the user closes the application and later reconnects to transfer his changes? That's a step between your "they're modified" and "when they come back". We think about the client having it's own database, which the client works on until the connection to the server is reestablished.

You can do that, but you then obviously lose change tracking information (i.e.: field Foo is changed in entity Bar). You can also write the entities to XML, save the XML, and re-instantiate the entities back from XML later on, which will preserve change tracking information.

Otis wrote:

You can also use a UnitOfWork object, which is serializable, to which you can add entities to be deleted as well. You then send the UnitOfWork to the server and commit it. All actions recorded with that unitofwork object are then executed in a transaction.

Why should we add entities to be deleted to such a UnitOfWork? What is so special about deletion (why did you mention this)? Are deletion markers only supported for this UnitOfWork stuff or is it generally possible to mark an object as deleted in a similar way as a row becomes marked as deleted in a DataTable?

A UnitOfWork is the object with which you can collect work to be done, i.e.: saving/deleting etc. It;s serializable so you can send it to various tiers and servers/services without problem. The point about 'marking' something for deletion is that everything in LLBLGen Pro requires an action, and deletes are not an exception. Deletes are considered irreversable, so extra care has to be taken. What you want to achieve can be done with for example a UnitOfWork.

In an earlier thread, I asked you about differences between LLBLGen and TierDeveloper.

I found the answer myself: it's your support.

Thanks for your help and engagement.

Mario

mario.muja wrote:

In an earlier thread, I asked you about differences between LLBLGen and TierDeveloper.

I answered the posting, I hope you've seen it

I found the answer myself: it's your support.

I hope more than just support

Thanks for your help and engagement.

You're welcome