Thanks Kevin

So...hopefully that gives another explanation on the value of interfaces. In general, they are great (and basically essential) for distributed development.

So, to play devil's advocate, why would I not just write a class to access the public
members of the server side component? In other words, why not just write a class
with

GetCustomerRecord(int CustomerId)

regardless of the interface?



(If you're interested in WCF, I can post the code for the server side/client side steps for this example)

I would like that. Please do.

Thanks






>Hey, Kevin,
>
>Here's another example of how interfaces are fundamental: in Windows Communication Foundation (WCF).
>
>Suppose you have some kind of distributed architecture. One of the modules in your app is a basic customer module, with code on the server side to retrieve client master data by a client ID, and also to retrieve client history data for a client ID.
>
>So you have two functions in a basic customer business class:
>
>

>string GetCustomer(int CustomerID);      // both return XML strings
>string GetOrderHistory(int CustomerID);
>

>
>Now, these functions will reside in a class on the server side.
>
>OK, basic stuff....but now you have the client piece, and you want the client piece to call these back-end classes. Trouble is, the client piece is on a different location/domain/server/etc, and can only access the server through TCP, or HTTP, etc.
>
>You sure don't want the client piece to have to have a copy of the server-side customer class (not only because you don't want to have to push out DLLs, but also because that customer class may be accessing a data access piece that's physically unavailable to the client piece). So you want every layer to execute code on the domain where the layer resides.
>
>So...what to do? Well, here's where interfaces come in. From a technical standpoint, what you want to do in a client piece is work with an interface to these back-end functions, like so:
>
>

>[ServiceContract]
>public interface ICustomer
>{
>    [OperationContract]
>    string GetCustomer(int CustomerID);
>    [OperationContract]
>    string GetOrderHistory(int CustomerID);
>}
>

>
>(Note the ServiceContract and OperationContract references...I'll get to them in a minute)
>
>When the client and server pieces share this simple interface, it allows the client to do the following
>
>1) In design mode, the programmer can create a proxy object that implements the interface
>2) The programmer can work with that object and use discovery (intellisense), as if the class object were local
>3) At runtime, we can use WCF to specify the actual address and communication binding (TCP, HTTP, etc.) for the proxy object.
>
>So this fits in with what Bonnie said about "programming to an interface". In this instance, the client doesn't "need" the full back-end customer class. All the client needs is an interface. The interface guarantees (and that's why people refer to an interface as a contract) that any class implementing that interface will contain specific properties and methods.
>
>So you can be confident in developing/coding against that interface, knowing that the actual back-end object will contain the same props and methods you're working with. You don't so much care "how" GetCustomer and GetOrderHistory work....you mainly care "what" you give them and receive from them: they take a customerID as a parameter, and return XML strings as results.
>
>So...hopefully that gives another explanation on the value of interfaces. In general, they are great (and basically essential) for distributed development.
>
>(If you're interested in WCF, I can post the code for the server side/client side steps for this example)
>
>Hope that helps...
>Kevin