Hi,
I've read and learned quite a bit from your Expert VB 2005 Business Objects, and I've used some of the concepts to implement my own architecture. I wanted to use .NET Remoting for running some of my objects from a client on a server, but I have a problem. All my objects either inherit from a class called OBase(of T) or OBaseList(Of T). OBase(of T) can inherit from MarshalByRefObj like I need it to to remote all my objects that dervice from it, but OBaseList(Of T) already inherits from BindingList(Of T). ...so how can I possibly make my list objects run on the server, since I can't have OBaseList(Of T) inherit from both BindingList(Of T) and MarshalByRefObj. Is there a way around this that I can't think of? Any help would be appreciated.
Also, what if I went the Enterprise Services route for remoting instead of .NET Remoting - then will it work if I create one object called RemotObjectCreator that inherits from ServicedComponent and use that object to create all my other objects on the server and returns a reference of those to the client? Will those object's methods run on the server when called then since they were returned by reference, or no because they themselves don't inherit ServicedComponent (which would bring me back to square one since I can't have OBaseList(Of T) inherit from anything else but BindingList(of T)???
Thank you!!
You can't, and shouldn't, have an object that is both anchored (see Chapter 1) and which implements your domain object model. As you note, there are many base classes in .NET that aren't anchored, but which you need to implement common scenarios.
You are best off thinking about one set of objects that expose methods or services across the network, and another set of objects that implement your business model.
In the case of CSLA .NET, the business model objects are mobile objects (see Chapter 1). But you can use similar techniques to create a server-only object model that would run behind your MBRO service objects.
It is important to realize, however, that it is virtually impossible to create a rich set of server-only business objects and still implement them in an object-oriented manner. The reality is that the client can't call across the network to get each object property, or each row in a collection - at least not if you value any sort of performance.
Thanks - I see your point. ...I can't at this point in our development change our architecture though, so it seems remoting this way may be out of the question. But what if I had one MarshalByRefObject that I run on the server that I just use to pass my business objects (which aren't marshalbyref, but still serializable) by ref to the server and pass a method and it's parameters to call on them to this object. Would this be a good workaround?
Say I have a class called RemoteObjectRunner:
Public Class RemoteObjectRunner
Inherits MarshalByRefObj
Public Sub RunObjectAndItsMethodOnServer(ByRef myBusinessObject As Object, ByVal methodName As String, ByVal parameters As Object())
'call "methodName" on myBusinessObject here - will this method run on the server this instance
'of RemoteObjectRunner is running on then? ...that seems like it could work
'...so something like this:
Dim myMethod As MethodInfo = myBusinessObject.GetType.GetMethod(methodName)
myMethod.Invoke(myBusinessObject, parameters)
End Sub
End Class
So would passing my local business objects to this server object to call a method on them that I want run on the server work?
For example, if I have an instance of my object called myObjectInstance and wanted to call it's Save method, but want it run on the server, will then calling: RunObjectAndItsMethodOnServer(myObjectInstance, "Save", Nothing) cause it to be run on the server the way I've proposed implementing the RemoteObjectRunner object? ...sorry if I'm reiterating what I want to do - I have trouble explaining myself sometimes, and want to make sure I'm being clear about what I want to do.
Thank you again!!!
Yes, in concept this is exactly what the data portal does, though it imposes some more formal structure than what you are proposing.
In the simple case, this is pretty easy to implement. You may find, like I did, that you often want to step beyond the simple case, and then things can get very complex. The data portal now implements almost all the functionality of the late binder in the VB runtime, for example, because I ended up needing to support generic types, method overloads and so forth.
But if you can avoid the use of generic types and methods, and avoid using Overridable methods you should be set.
OR, since you are using VB, you could specify that the method to be called on the server must be a public method. Then you could just let VB's pre-built late binder do the work for you by setting Option Strict Off in your server-side calling file.
I hope that makes sense? VB already fully supports all the fancy coding necessary to do a late bound call on a public method. The only reason I wrote all that reflection code in the data portal is because I'm calling non-public methods (well, and because I also need a C# implementation, and C# doesn't have the dynamic language features of VB).
If I were doing a pure VB implementation, and was willing to require that the method-to-be-called had to be public, I'd just use the built-in dynamic language capabilities of VB itself.
Copyright (c) Marimer LLC