User-Defined Class Loaders?

I've just been reading about user-defined class loaders in Java. Does .Net have this facility?

John Topley
Wednesday, November 06, 2002

No.  When asked why Microsoft sites security concerns.

Fred Flintstone
Wednesday, November 06, 2002

I've written Java class loaders, and I've had to deal w/ the effects of class loaders and how they're used in various Java-based app servers. When they're used well, they are nice. But more often that not, they get in the way of what would otherwise be normal app-development expectations.

.NET has "AppDomains", probably the most analogous thing to class loaders. The two items are, I think, trying to solve the problem of keeping logically distinct applications partitioned when running in a single physical OS process. The prototypical example is a web app server running multiple web apps. AppDomains seem to handle that issue well enough w/o the complexities of the class loader approach.

FWIW...

Donnie

Donnie Hale
Wednesday, November 06, 2002

Thanks. Java class loaders can also be used for dynamic extension, does .NET allow anything similar?

John Topley
Thursday, November 07, 2002

.NET can load new types at runtime using methods of the Assembly object.  I don't know enough about java to know whether that's an equivalent to dynamic loading or not. What does java dynamic loading do?

Mike Gunderloy
Thursday, November 07, 2002

From http://www.artima.com/designtechniques/dynaext.html

"Java's architecture enables you to write programs that dynamically extend themselves at runtime. Java programs can dynamically extend themselves by choosing at runtime classes and interfaces to load and use.

Looked at another way, dynamic extension means that at compile time, you don't necessarily need to know about all the classes and interfaces your program will use at runtime. In fact, some of those classes and interfaces may not even exist when you do your compile."

John Topley
Thursday, November 07, 2002

.Net can do the same.  You use the Assembly.Load or Assembly.LoadFrom method to load a type.  You can examine the type to see what properties/ methods/ interfaces, etc. that it supports, then use those members.

Personally I don't see the need for this much flexibility.  I've never had to load a completely unknown type before.

Fred Flintstone
Thursday, November 07, 2002

One place I've used this in .NET is with a pluggable archictecture - a program that allowed many different "sensors" to be plugged in to an overall framework. An XML configuration file specifies the sensors to load, then the code uses Assembly.LoadFrom to get the types into the AppDomain. Works fine.

Mike Gunderloy
Thursday, November 07, 2002

Replying to "Mr. Flintstone" above (cute) - there are two ways to go w/ dynamic loading. You can load types dynamically which implement already-known interfaces. You can then invoke instances of those types via those known interfaces. So there's some compile-time safety in that situation, and you risk getting cast exceptions at runtime if the dynamically loaded type doesn't support the expected interface.

The second way is to dynamically load types and use reflection to locate properties/methods on those types and invoke them via the appropriate reflection construct. I've used this technique in both Java and .NET to write generic object-relational mapping layers.

FWIW...

Donnie

Donnie Hale
Friday, November 08, 2002

I have dynamically loaded types (in order to implement an 'add-ins' object model), but these types all inherited from one known interface or another.

In your second paragraph your mention "...write generic object-relational mapping layers."  Could you expand on that?

Fred Flintstone
Friday, November 08, 2002

Expanding on "generic object-relational mapping layers"... By way of background, I'll state that I have a strong penchant for certain design patterns in distributed apps. Martin Fowler had an excellent site up on enterprise patterns, but it's down now since the book is out. Also, I strongly believe that apps should take as much advantage of the features of relational DBs as possible. Many O-O advocates focus so much on modelling the objects that the data layer is neglected. Correspondingly, most of the O-R mapping libraries I've come across want to base the DB schema on the object model and, in fact, generate schema creation code from the object model. I'd much rather fully define the data model, including constraints and everything, i.e. full DRI, as much of that can't be inferred/generated from the object model.

Given that, when I start developing an app, I've got a complete data model represented as a database. I don't want to have to write SQL CRUD code for every entity. I don't want to have to hand-write data transfer objects (DTOs - from Fowler's patterns) for every entity. So I've written an O-R library which reads a .xml file defining tables to be mapped to DTO object names, etc. It will auto-deduce property names or you can explicitly specify them. It works for the OleDb, Odbc, and Sql .NET providers.

It uses CodeDOM to generate the DTOs. It generates the SQL needed for the tables, plus you can specify other select statements which should map to the DTO for a table. BTW, that's another goal - using standard SQL, not EJBQL or some other pseudo-SQL dialect. Reflection is obviously needed when it comes time to populate a DTO with the results of a query or to create the parameters for a SQL statement to update the DB.

Not sure if that answers your question or not, but at least the message is lengthy. ;)

Donnie

Donnie Hale
Tuesday, November 12, 2002

  Recent Topics

  Fog Creek Home