s WEB FORMS UI in C#.NET

Creation PDF 417 in C#.NET s WEB FORMS UI

All of the pages dealing with business data use the exact same objects as the Windows Forms UI in 9. The same ProjectTracker.Library assembly created in 8 is used for the Windows, web, and Web Services interfaces in this book. The web forms using those objects are built using data binding, relying on the CslaDataSource control discussed in 5.

The site needs to provide some basic configuration information through the web.config file. This includes configuring the data portal or database connection strings. It also includes configuring the CslaDataSource control. In the web.config file, you can either provide connection strings so that the site can interact with the database directly, or you can configure the data portal to communicate with a remote application server. The basic concept here was discussed in 4 when the channel adapter implementation was covered. Recall that the data portal supports three possible channels: remoting, Enterprise Services, and Web Services. You can create your own channels as well if none of these meet your needs. In 1, I discussed the trade-offs between performance, scalability, fault tolerance, and security that come with various physical n-tier configurations. In most cases, the optimal solution for a web UI is to run the data portal locally in the client process. However, for security reasons, it may be desirable to run the data portal remotely on an application server. 12 will demonstrate how to create the three types of remote data portal hosts for use by the PTWeb application. The web.config file is an XML file that contains settings to configure the website. You use different XML depending on how you want the site configured.

The data binding in this chapter will rely on the CslaDataSource control discussed in 5. In order to use this control in Web Forms, the site needs to define a control prefix for any controls in Csla.dll. I ll use the prefix csla. This prefix is defined either in each web form, or in web.config. Since most pages will use the control, it is best to define the prefix in web.config so it is available site-wide. You ll find this element within the <pages> element: <controls> <add tagPrefix="csla" namespace="Csla.Web" assembly="Csla"/> </controls> This globally defines the csla prefix to refer to the Csla.Web namespace from Csla.dll. With this done, all pages in the website can use the prefix like this: <csla:CslaDataSource id="MyDataSource" runat="server"/>

The way authentication is handled by CSLA .NET is controlled through web.config: < xml version="1.0" encoding="utf-8" > <configuration> <appSettings> <add key="CslaAuthentication" value="Csla" /> </appSettings> </configuration> The CslaAuthentication key shown here specifies the use of custom authentication. 8 implemented the PTPrincipal and PTIdentity classes specifically to support custom authentication, and the UI code in this chapter will use custom authentication as well.

If you want to use Windows authentication, change the configuration to this: <add key="CslaAuthentication" value="Windows" /> Of course, that change would require coding changes. To start, the PTPrincipal and PTIdentity classes should be removed from ProjectTracker.Library, as they would no longer be needed. Also, the login/logout functionality implemented in this chapter would become unnecessary. Specifically, the Login form and the code to display that form would be removed from the UI project.

The web.config file also controls how the application uses the data portal. To have the website interact directly with the database, use the following (with your connection string changed to the connection string for your database): < xml version="1.0" encoding="utf-8" > <configuration> <appSettings> <add key="CslaAuthentication" value="Csla" /> </appSettings> <connectionStrings> <add name="PTracker" connectionString="your connection string" providerName="System.Data.SqlClient" /> <add name="Security" connectionString="your connection string" providerName="System.Data.SqlClient" /> </connectionStrings> Because LocalProxy is the default for the data portal, no actual data portal configuration is required, so the only settings in the configuration file are to control authentication and to provide the database connection strings.