email article printer friendly

Tips on Making ASP.NET Design Decisions
User controls or server controls? Web services or remoting? Here's how to choose the right tool for the ASP.NET job.
by Jonathan Goodyear, MCSD, MCP, CLS

Posted April 16, 2002

There are several instances where multiple parts of ASP.NET appear to do the same thing. Choosing between your various options can be difficult. Here are some quick hints to help you choose the most appropriate tool for the task at hand.

User Control vs. Server Control
ASP.NET offers two alternative approaches for user interface code encapsulation. You can either build server controls or user controls.

If you are aggregating user interface elements to solve a business specific purpose, a user control is ideal. This is especially true if you are not as concerned about hiding your source code. One of the most important reasons you would opt to build a user control is to leverage partial page caching. You can do almost anything with a user control that you can do with a server control. Generally speaking, think of user controls at a macro level, and server controls at a micro level. A good example of a user control would be a reusable e-mail form that you can place in several different places on your Web site to collect feedback that goes to multiple destinations.

Server controls are much more complex and difficult to build, so they should be reserved for small, distinct, and unique user interface elements. Server controls also provide an effective mechanism for building user interface elements based on repeatable templates if you need them. If you plan to sell your control, server controls make a better choice because you can completely hide their implementation. With user controls, only the code-behind class can be hidden, which then requires you to distribute multiple files to any client of the control. Server controls are designed to be compact and easily distributable. A good example of a server control would be an optimized TextBox control that implements some numeric formatting logic.

Web Services vs. Remoting
Both Web services and remoting allow you to communicate with remote systems. Web services are a good choice if the clients of your service are "outside" your system domain. This is because they include a WSDL file that describes the interface for your service, enabling clients to consume it more easily. Web services are also able to leverage caching quite easily using the CacheDuration property of the WebMethod attribute on your Web service class definitions. Web services are standards-based and platform-independent in all respects, so if you are planning for your services to traverse multiple platforms, Web services are for you. A good example of a Web service is a company phone directory.

Remoting is optimal when you need the greatest amount of configuration flexibility. You can maximize performance by opting to use the proprietary .NET binary protocol for communications. You can also use the SOAP protocol if you must communicate with non-Windows systems, although remoting shines best with .NET to .NET communication. You can still use remoting even if you are not hosting your application on a Web server, which opens up many opportunities for peer-to-peer communications. Complex objects are supported more easily with remoting, and remoting allows you to invoke multiple methods on a stateful object. Remoting would be an ideal tool to use if you were building your own proprietary Instant Messaging client. Microsoft's Terrarium project is another perfect example of remoting at its finest.