According to some of the books I have been reading, like Advanced C# Remoting by Ingo R., it is considered best practice to keep your data access implementation away from the client.

That being said, in order for a developer to create an instance of a typed object on the client, the type definition (i.e. meta data) needs to be on the client. There should also be some sort of contract between the client and the server side implementation that ensures that the client wont be attempting to invoke methods that are not on the server anymore, i.e. a public interface that defines the server side methods.

My solutions typically follow these guidelines, there is a presentation layer, a facade layer, and a framework layer. The framework layer consists of the llblgen entities and the database specific objects, or sometimes I have a selfservicing framework. The facade typically always consists of a mix of fine grained methods and coarse/broad methods. The fine grained methods are chatty methods, like "get this data by some key", etc. and the broader methods are major things like "here is a group of invoices and all of their associated invoice details, now go do updates and inserts based on the internal business rules and implementation."

So now that we know how I write apps, and what the "best practices" are, we arrive at my question. In my opinion, I can use the adapter pattern and publish the database generic assembly to the client, because it doesnt contain any implementation for data access operations. I also beleive that I can wrap facade objects into objects that derive from MarshalByRefObject and implement my public interfaces. I should only need to distribute the public interfaces, the database generic assembly, and the LLBLGen.ORMSupport assemblies to the client.

Does my opinion on how I should implement remoting seem to be normal or overly complicated? Here is the flip side, I could just skip remoting all together and use COM+ / Enterprise Services, but that really is remoting, and in my personal experiences, COM+ proxy deployment can be a nightmare.

Any opinions on this topic would be greatly appreciated.

Cheers

Avoid MarshallByRefObject at all costs for entity objects or objects containing these objects. The reason for that is that for each property access or method call you have a roundtrip to the server. This is killing for scalability.

It's also unnecessary, as you can better just create a service object which you MarshallByRefObject to the client (and which thus lives on the server) and which you use to retrieve entity objects or pass entity objects back to the server. The entity objects are MarshalledByValue, which means that a copy is created on the client, not a proxy. This is much more scalable as you don't have a roundtrip to the server when you access a property or method.

So for example, would the code below meet the criteria that you are describing:

Client:

sub cmdClick()
        Dim obj As Object
        obj = Activator.GetObject(GetType(IRemoteObject), "SOME URL TO YOUR REMOTE OBJECT")
        Dim remoteObj As IRemoteObject = CType(obj, IRemoteObject)

        dim customer as new EntityClasses.Customer("CHOPS")
        customer.IsNew = False
        customer.Name = "Bob"
        if remoteObj.UpdateCustomer(customer) then
             msgbox("Data Saved")
        else
             msgbox("Update Failed")
        end if
end sub

** Server:**

Public Interface IRemoteObject
    Function UpdateCustomer(customerToUpdate as EntityBase2) As Boolead
End Interface

Public Class RemoteObject
    Inherits MarshalByRefObject
    Implements IRemoteObject

Public Function UpdateCustomer(customerToUpdate) As Boolean Implements IRemoteObject.UpdateCustomer
           dim myFacade as new Facade.CustomerServices
           return myFacade.SaveData(customerToUpdate)
    End Function

End Class

Thanks for the input.

Yes.

Great, thanks for the help Otis.