When creating business objects, I have typically used the factory pattern to create a concrete type. As you know the details of how the object is created are hidden from the developer. Except that the developer has to use the factory, which is not entirely natural for creating objects.
What I wanted to do is be able to create objects, using the new operator, and have the objects created just as if they had been created using the factory. It seems to me that the syntax is much more natural. For example: MyObject obj = factory.CreateObject(typeof(MyObject)); is less natural and less intuitive than MyObject obj = new MyObject(). I have fooled around with the ProxyAttribute and ContextBoundObject and have successfully created my object. I just don't like having to inherit from ContextBoundObject and hoped that there was a better way for non-remotable objects. Chris ----- Original Message ----- From: "Marsh, Drew" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Friday, June 07, 2002 1:46 PM Subject: Re: [DOTNET] .Net Remoting and CreateInstance > Chris Rolon [mailto:[EMAIL PROTECTED]] wrote: > > > In the past I would have used a factory pattern for this > > behavior. I was just wondering if there was a better way using .Net. > > I would still use the factory pattern, but you *can* technically use the > ProxyAttribute even for non-remote objects. All you're doing is hiding the > fact that a factory is in place with this approach though. The factory just > becomes your ProxyAttribute subclass. Usually though, a factory instantiates > a concrete type and returns it via some abstract interface... what exactly > is it that you need to intercept/do at instance creation? > > Later, > Drew > .NET MVP > > You can read messages from the DOTNET archive, unsubscribe from DOTNET, or > subscribe to other DevelopMentor lists at http://discuss.develop.com. > You can read messages from the DOTNET archive, unsubscribe from DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com.
