Home
Help
Register
Log in

Search

 
   Active Threads  

You are here: Home > LLBLGen Pro > LLBLGen Pro Runtime Framework> Transaction in constructor
 

Pages: 1
LLBLGen Pro Runtime Framework
Transaction in constructor
Page:1/1 

  Print all messages in this thread  
Poster Message
Rob
User



Location:
Gold Coast, Queensland, Australia
Joined on:
17-Sep-2004 13:51:52
Posted:
50 posts
# Posted on: 05-Mar-2010 05:28:56.  
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:
Code:

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


When I could perhaps instead do this:
Code:

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
  Top
Walaa
Support Team



Location:

Joined on:
21-Aug-2005 16:03:48
Posted:
14453 posts
# Posted on: 05-Mar-2010 08:32:49.  
You may modify the entity template to add this CTor.

  Top
Rob
User



Location:
Gold Coast, Queensland, Australia
Joined on:
17-Sep-2004 13:51:52
Posted:
50 posts
# Posted on: 05-Mar-2010 10:38:30.  
Gee, thanks Walaa

That really helped.
  Top
Otis
LLBLGen Pro Team



Location:
The Hague, The Netherlands
Joined on:
17-Aug-2003 18:00:36
Posted:
37319 posts
# Posted on: 05-Mar-2010 10:47:59.  
Not sure if you're being sarcastic or not Wink, 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 Wink


Frans Bouma
LLBLGen Pro / ORM Profiler Lead Developer | Blog | Twitter
 
Top
Rob
User



Location:
Gold Coast, Queensland, Australia
Joined on:
17-Sep-2004 13:51:52
Posted:
50 posts
# Posted on: 05-Mar-2010 10:59:02.  
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
  Top
Pages: 1  


Powered by HnD ©2002-2007 Solutions Design
HnD uses LLBLGen Pro

Version: 2.1.12172008 Final.