Hi guys!

I have a little suggestion that would make my life just that little bit easier.

I wonder if you could add a constructor to the entity classes that takes the PKs and a Transaction object?

Right now I have to do this more often than not:

ProductEntity templateProduct = new ProductEntity();
dbtxn.Add(templateProduct);
templateProduct.FetchUsingPK(templateProductID)

When I could perhaps instead do this:

ProductEntity templateProduct = new ProductEntity(templateProductID, dbtxn);

It is obviously no biggie, but it would make life easier and code more readable.

Ok, let me know why this is a bad idea.... ;-)

regards,

!Rob

You may modify the entity template to add this CTor.

Gee, thanks Walaa

That really helped.

Not sure if you're being sarcastic or not , but let's assume you're not: you can add this ctor yourself in a partial class as well, if you want. The reason the ctor doesn't accept a transaction is that there are already a lot of ctors, and adding this would extend the set of ctors with yet another couple of overloads (as there have to be variants with and without a transaction).

The same is for prefetch paths, excludingfields lists etc.: these too could have their own ctor, but this too would lead to a lot of ctors and that's not really that great. In the beginning we chose the set of ctors we have now, and as we can't remove them now, it might have been a good idea to drop the validator accepting ctor instead for this one, but alas, that's life

Fair enough,

I am aware of having to stick to the chosen path in a large project. As I am adamant not to wreak havok with your excellent templates I will consider adding my own constructor in each class that I customise.

I still think it was a good idea, but I completely accept your rational for dismissing it.

Regards,

!Rob