Re: Table bloat in Linq-SQL
- From: "Andrus" <kobruleht2@xxxxxx>
- Date: Mon, 12 Nov 2007 19:47:55 +0200
Jon,
I think he means the Table<T> - on the RDBMS there wouldn't be
anything triggering assemblies being loaded etc (typically, anyway).
But yes, some more clarity would be nice :)
I'm sorry I was not clear.
Table<T> object instantion causes assembly containing type T to be loaded.
So my issue is: is it possible and reasonable to change sqlmetal generated
code
so that it does not create tables in Data Context constructor?
Is it possible and reasonable to move table creation to table property
getter by implementing getter like
public readonly MTable<Customer> Customers {
get { if ( customers=null )
customers = new MTable<Customer>(this);
return customers;
}
Will Linq-SQL work well in this case in design and run times ?
Or will only reference to Table<T> in assembly cause assembly containing
type T to be loaded ?
If so I think I will create whole extended properties assembly at runtime
and load it fully. If this causes perfomace decrease I hope I can cache this
extented assembly in isolated storage.
I havent seen any .NET application with uses background assembly loading at
startup like windows logon.
Andrus.
.
- Follow-Ups:
- Re: Table bloat in Linq-SQL
- From: Jon Skeet [C# MVP]
- Re: Table bloat in Linq-SQL
- References:
- Table bloat in Linq-SQL
- From: Andrus
- Re: Table bloat in Linq-SQL
- From: Jon Skeet [C# MVP]
- Re: Table bloat in Linq-SQL
- From: Andrus
- Re: Table bloat in Linq-SQL
- From: Frans Bouma [C# MVP]
- Re: Table bloat in Linq-SQL
- From: Jon Skeet [C# MVP]
- Re: Table bloat in Linq-SQL
- From: Frans Bouma [C# MVP]
- Re: Table bloat in Linq-SQL
- From: Jon Skeet [C# MVP]
- Table bloat in Linq-SQL
- Prev by Date: Re: C# Classes with members that implement IDisposable
- Next by Date: Re: Concurrency and delegates
- Previous by thread: Re: Table bloat in Linq-SQL
- Next by thread: Re: Table bloat in Linq-SQL
- Index(es):
Relevant Pages
|