Saving objects

Posts   
 
    
Answer
User
Posts: 363
Joined: 28-Jun-2004
# Posted on: 27-Apr-2005 08:21:35   

Guys,

i am going to use Adapter and LLBGen over webservices. But i am curious as to how i should implment a few things.

Say you have a function called SaveOrder(OrderEntity orderEntity)

Now, the orderEntity also contains a few orderItemEntities that have changed. So the runtime will traverse the graph and save them. Which is fine and dandy. BUT orderEntity is also related to CustomerEntity, and that has changed as well, but my function SaveOrder should NOT Be saving the customerEntity.

With datasets i could just make a typed Dataset with only the Order DataTable and OrderItem datatable.

I know there has got to be a way to restrict the saving of the object graph or something. OR i am going about this all wrong? If not i may as well just create one webservice to save all entities.

Otis avatar
Otis
LLBLGen Pro Team
Posts: 39749
Joined: 17-Aug-2003
# Posted on: 27-Apr-2005 11:01:33   

What if the customer is new? In that case you can't save the order, you have to save the customer then.

There isn't a way to specify 'here you have a graph of 10 layers with 51 objects and you have to save this, this and this entity and the rest you can ignore'. The problem with that is that it's easier to simply dump the entities to save in an EntityCollection and save non-recursive simple_smile

Frans Bouma | Lead developer LLBLGen Pro
Answer
User
Posts: 363
Joined: 28-Jun-2004
# Posted on: 27-Apr-2005 17:50:55   

What if the customer is new? In that case you can't save the order, you have to save the customer then.

AHHH, frans the genius smile I didnt think about that. But what if i need to do some business logic prior to saving that customer to verify something or another?

simply dump the entities to save in an EntityCollection and save non-recursive

So if i understand correctly. I would call Save twice, once for teh order entity, and once for the OrderItems entity Collection. This would then not follow the graph, assuming i told save to be NON recursive. That would work.

I thought of something last night, but it doesnt appear the designer supports it. One solution i thought up was to create the Order entity and Orderitems in the designer, then get rid of all relations to those two entities, just keep the relation between the OrderEntity and the OrderItemsEntities. Then add ANOTHER OrderEntity (name it slight different obvisously) and another OrderItemsEntity(again name it different, orderitems1 or something) to the project. Leave all relations connected to it.

I could see this possibly being useful. I dunno, i dont think it woudl be hard to implement. In this case, i could except OrderEntity as parameter to my function and save can still be recursive since only OrderItems is connected to it.

Skeeterbug
User
Posts: 165
Joined: 21-May-2004
# Posted on: 27-Apr-2005 20:16:27   

Are the users going to be able to change customer information tied to your order on the order screen? Chances are they won't have access to it. I wouldn't really worry about this.

Answer
User
Posts: 363
Joined: 28-Jun-2004
# Posted on: 27-Apr-2005 22:00:59   

What if its being exposed as a webservice? Any old program can come in and hookup to it. Yeah i could do authentication and just use the method that Frans mention, do a manual recursive save, which is probably the route i will take. By not doing checking though, you leaving holes up for people to change stuff they shouldnt be changing.

IE, my SaveOrder() function should be checking just BL related to Orders, not everything an Order is related to.

Otis avatar
Otis
LLBLGen Pro Team
Posts: 39749
Joined: 17-Aug-2003
# Posted on: 28-Apr-2005 12:08:01   

Answer wrote:

What if the customer is new? In that case you can't save the order, you have to save the customer then.

AHHH, frans the genius smile I didnt think about that. But what if i need to do some business logic prior to saving that customer to verify something or another?

Either use an EntityValidator or pass the graph to a routine which performs the validation. The routine accepting the graph knows that the graph is send to be saved, so it knows exactly when to call that routine, namely directly when it gets a graph simple_smile

simply dump the entities to save in an EntityCollection and save non-recursive

So if i understand correctly. I would call Save twice, once for teh order entity, and once for the OrderItems entity Collection. This would then not follow the graph, assuming i told save to be NON recursive. That would work.

Indeed, though I'd set it up so the PL doesn't have to deal with that. Simply pass the graph to the BL and the BL has to figure it out.

I thought of something last night, but it doesnt appear the designer supports it. One solution i thought up was to create the Order entity and Orderitems in the designer, then get rid of all relations to those two entities, just keep the relation between the OrderEntity and the OrderItemsEntities. Then add ANOTHER OrderEntity (name it slight different obvisously) and another OrderItemsEntity(again name it different, orderitems1 or something) to the project. Leave all relations connected to it.

I could see this possibly being useful. I dunno, i dont think it woudl be hard to implement. In this case, i could except OrderEntity as parameter to my function and save can still be recursive since only OrderItems is connected to it.

You can also set orderItem.Customer = null before passing it to the adapter in the BL.

Frans Bouma | Lead developer LLBLGen Pro
Answer
User
Posts: 363
Joined: 28-Jun-2004
# Posted on: 28-Apr-2005 17:35:32   

That is what i will do Frans. Thanks for the help!