CODEWITHSUNDEEP
.netwcfweb-servicesmodel-view-controller
gahooa
gahooa

Reputation: 137492

Best Approach to Writing an Enterprise Application with Windows and Web Interfaces?

I am working on the architecture of a large enterprise application which will be based on the latest .NET and SQL Server technologies. This application will be used by the general public, members, employees, and managers.

In the past, we have used RemoteApp / RemoteDesktop to talk to a local Windows Forms application running on the server. Simple, but clunky.

The windows application needs to be distributed to a geographically disparate audience (branch managers and employees).

Here are the objectives of the windows interface:

  1. a "thin client", where it behaves similar to a web browser (user interface only)
  2. all of the processing to be done on the server
  3. utilize the same codebase that the web-app does -- just different UI
  4. Straightforward to develop (easy to maintain and grow)

What are some of the best approaches to this?

(I have spent a fair amount of time looking at .NET Remoting and then WCF, but I don't have the clairty of experience, which I hope you can bring.)

Thanks!

Upvotes: 3

Views: 1198

Answers (1)

Tridus
Tridus

Reputation: 5081

I have an application at work that features a web interface, and a WCF service interface. Another application (a WinForms one) uses the WCF service to provide the same functionality that the web app provides, only in the context of what the WinForms app is doing. The nice thing about it is that the actual functionality is in a business layer, and both the Web app and the WCF service are simply presenting a different UI & method of access.

From what you're describing, something similar would work. The real key is to make sure that as little business logic as possible is embedded in ASPX pages. Any that is, you will have to re-create for the WCF side of it.

So you want to create a set of business logic classes that can perform the actual functions of the application. Your web pages then contain presentation logic. If you set it up that way, it's fairly straightforward to create a WCF service that exposes the same business logic to calling programs. This part is the real key to the whole thing. You only want the logic in one place, so that changing it will change it for both types of callers at once.

If you're using one of the web service WCF bindings, you'll be able to stick the service file inside your web app and host them together. If you're using things like active directory authentication, you'll be able to leverage that for both types of access at the same time (since this is an internal WCF service instead of an Internet public facing one, that will work fine).

I'd start with the web app side of it first, and once it does what you want you can add the WCF service afterward to keep the project to a manageable scale.

As for WCF vs remoting, in this case I'd favor WCF. It pairs REALLY well with web apps.

edit:

1) Interface - You'll need a class in a .svc file to implement the service calls no matter what. An interface is required as the service contract for some types of services (basicHTTPBinding, which is SOAP based), but not for others (webHTTPBinding, which is REST based). I'd probably write an interface anyway though, it lets you change the service implementation without changing the service contract, which is what needs to stay consistent for clients.

2) It's certainly possible to call the service from the web app, but it's going to add an extra layer of work to the web app. For the HTTP services it also means that your service will XML serialize everything, then your web app will need to deserialize it immediately. XML serialization carries a significant performance hit. I'd avoid this method, as the web app can databind to the business objects being returned by the business layer a LOT more effeciently (and WCF will XML serialize it for clients of the service automatically). It'd be one thing if your web app needed to call another service in a different app, but in this case it's not the way to go.

3) If it's public facing, how you authenticate it changes. For internal stuff you can let IIS handle the authentication using Active Directory. If you've got Internet clients, they're probably not in Active Directory and you'll need to use some other method. (HTTP Basic and Digest auth should still be alright, or you can do something like add the username/password as parameters to methods that need authentication. Be sure to use SSL on the service!)

Upvotes: 2

Related Questions