Distributed Applications
-
I'm working on a distributed application, and I would like to only have the WinUI on the client machine, and keep DataAccess, BusinessRules, BusinessFacade and so forth, on a server. Is this posible? If so, how? Does anyone know of any articles related to this? this program will be used from anywhere between three and three hundred people at a time. excuse any typing mistakes, its 4am :) ~Dan
-
I'm working on a distributed application, and I would like to only have the WinUI on the client machine, and keep DataAccess, BusinessRules, BusinessFacade and so forth, on a server. Is this posible? If so, how? Does anyone know of any articles related to this? this program will be used from anywhere between three and three hundred people at a time. excuse any typing mistakes, its 4am :) ~Dan
Dan Smith wrote: Is this posible? Yes Dan Smith wrote: If so, how? There are several different ways of doing this and what you use depends on your requirements. The easiest way is to expose a webservice on your server and have the WinUI use it. There is a section on webservices which may enlighten you on how to create them, if you're using VS.NET they're easy to use as well (right click on the WinUI project and choose Add Web Reference, then point the mini-browser to your deployed web service). By default web services are stateless, but it should be possible to use the ASP.NET Session stuff to persist bits and pieces. Your next option is to use Remoting. Remoting is a bit harder to put together and use, but it is more powerful as well. Nish wrote a good article on the basics of remoting. http://www.codeproject.com/csharp/absoluteremoting.asp[^] You may also want to check out the sample chapter from Ingo Rammer's book for a bit more indepth look Advanced .NET Remoting[^]. Good luck, James - out of order -
-
I'm working on a distributed application, and I would like to only have the WinUI on the client machine, and keep DataAccess, BusinessRules, BusinessFacade and so forth, on a server. Is this posible? If so, how? Does anyone know of any articles related to this? this program will be used from anywhere between three and three hundred people at a time. excuse any typing mistakes, its 4am :) ~Dan
Start with building a ASP.NET Web Service. This class will be your Facade, and will invoke your business rules, and data access layers. If your architecture supports .NET code on both client and server, you can pass managed DataSets across the boundry, which will make both sides easier to write. From what I understand, you UI will be a System.Windows.Forms application. You add a web-reference to your ASP.NET Web Service to that project, and invoking methods on the facade will be a breeze. For example, the UI want's to start with a list of customers. It calls a method on the facade: GetCustomerList( string territory ) which returns a DataSet. Behind the facade, you've got business rules that check if the user is authorized for that territory, etc. Once validated, a data access layer pulls a limited set of fields needed for this list out of the databse, limited to the specified territory, and returns it as a DataSet. This list might have just Customer Name, City, State, ZIP and ID. Back on the client, you can drop that dataset write into a grid control to format, scroll, etc. Without round-tripping, you can sort of any of the fields. Once the user selects a customer, you call another facade method: GetCustomerDetails( string customerID ) which also returns a DataSet. If changes are made, call facade method UpdateCustomerDetails( DataSet details ). Hope that gets you started... Burt Harris
-
Start with building a ASP.NET Web Service. This class will be your Facade, and will invoke your business rules, and data access layers. If your architecture supports .NET code on both client and server, you can pass managed DataSets across the boundry, which will make both sides easier to write. From what I understand, you UI will be a System.Windows.Forms application. You add a web-reference to your ASP.NET Web Service to that project, and invoking methods on the facade will be a breeze. For example, the UI want's to start with a list of customers. It calls a method on the facade: GetCustomerList( string territory ) which returns a DataSet. Behind the facade, you've got business rules that check if the user is authorized for that territory, etc. Once validated, a data access layer pulls a limited set of fields needed for this list out of the databse, limited to the specified territory, and returns it as a DataSet. This list might have just Customer Name, City, State, ZIP and ID. Back on the client, you can drop that dataset write into a grid control to format, scroll, etc. Without round-tripping, you can sort of any of the fields. Once the user selects a customer, you call another facade method: GetCustomerDetails( string customerID ) which also returns a DataSet. If changes are made, call facade method UpdateCustomerDetails( DataSet details ). Hope that gets you started... Burt Harris
Burt Harris (msft) wrote: From what I understand, you UI will be a System.Windows.Forms application. You add a web-reference to your ASP.NET Web Service to that project, and invoking methods on the facade will be a breeze. Absolutely, here is a plug for my most recent article that cover how to do this: Cross Language Web Service Implementation[^], which includes a Windows Forms Web Service consumer application. :)
Nick Parker
Not everything that can be counted counts, and not everything that counts can be counted. - Albert Einstein