Lately we’ve been getting a number of requests for solutions that will require the use of forms, and the first reaction is usually “let’s use InfoPath”.  InfoPath is great for what it does, and is horrible for what it doesn’t.  This post will attempt to offer pros and cons for both InfoPath and ASP.NET ASPX forms, and hopefully will allow you to recommend the correct approach for an electronic forms solution.  This post assumes you’re considering InfoPath Forms Services (browser-enabled forms), as opposed to using the InfoPath client.

InfoPath Forms
Let’s begin by taking a look at InfoPath.  InfoPath is a great tool for creating simple data-entry forms, and for retrieving data from a variety of data sources.  In addition, it’s great when you need to submit data to a SharePoint form library for the purposes of leveraging a SharePoint workflow.  Where InfoPath breaks down is when we need to submit data to other sources, or when we need to provide a rich user-interface with robust controls and data validation.  Let’s take a look at some pros and cons of InfoPath:

Pros

• Great for submitting data to SharePoint or a SharePoint workflow
  Most of the time when we’re using electronic forms, it is to support a workflow process.  As you [should] know, a SharePoint workflow runs for a specific list item, and data needed for the workflow needs to be entered into the fields for that particular list item in order for the workflow to see it.  Because of this fact that the data actually needs to be a list item, InfoPath is a great choice, because you can effortless promote form fields as columns in your list, which the workflow can then use.
• Great for retrieving data
  InfoPath provides a very simple wizard interface for selecting a data source for data retrieval.  You can easily select a web service, and XML document, or a SharePoint list and have that data appear in your form pretty easily.  You can also connect to a SQL database and retrieve data from tables, views, or stored procedures.
• Great for simple end-user form development
  InfoPath is great for creating a simple form with a few fields and simple rules and simple data validation.  I keep emphasizing simple because once you introduce complex business rules, data validation, conditional formatting, or complex data presentation that pushes the limitations of InfoPath, you will be forced to get very creative which often involves some sort of custom coding.
• Most of the time only requires SharePoint site permissions
  Unless you are creating a browser-enabled form with .NET code-behind, or your form requires Full Trust and uses the InfoPath client, it’s relatively easy to deploy a form to SharePoint.  Simply publish the form to the desired form library and you’re good to go.  However, as soon as you introduce .NET code in a browser-enabled form, you need to install and activate the form to Central Administration and activate the newly-created feature at the site collection level.  You will need to have access to Central Administration and to the site collection in order to activate these features.

Cons

• Difficult to submit data to non-SharePoint data sources
  Like I mentioned, InfoPath is great for submitting data to a SharePoint form library.  It is not so great for submitting the data to anything else.  If your form is submitting data to a single (single being the operative word here), then you could potentially configure the form to submit directly to a table.  However if the data needs scrubbed or manipulated, chances are you will need to submit the data via a stored procedure, which InfoPath cannot do.  For this, you will be forced to develop a custom web service that accepts the data either field-by-field, or as a giant blob of XML that you have to parse through, which you then have to submit to the database by writing traditional ADO.NET code.  Not too simple anymore, huh?
• Limited user-interface
  InfoPath allows you to create forms with a variety of standard controls, such as textboxes, date pickers, radio buttons, checkboxes, buttons, drop-down lists, repeating tables, etc..  Unfortunately, it is pretty much limited to those items (you get a few more with the rich client, but that’s beyond the scope of this post).  You don’t have any type of tree view control, no multi-select list box, no tab control, no image buttons, and no grid view control. The lack of a grid view control is a deal breaker in many cases, because we often have to present long lists of data, and the built-in repeating table doesn’t support sorting, grouping, or paging.  Yuck.  Finally, there’s no way to add HTML or CSS to your form, meaning that it can’t inherit any SharePoint styles, and you’re limited to what you can design in the form.  This frequently gives an inconsistent look and feel for a SharePoint process.  Again, yuck.
• Difficult to secure sensitive data
  Assuming the InfoPath form is being submitted to a SharePoint form library, any data the form contains is inherently insecure.  The form is just saved to the form library like any other document, except as an XML document.  This means if your form contains social security numbers, salary information, or any other type of sensitive data, a user could download the XML file and open it in Notepad.  Even if the data isn’t visible through InfoPath, the data is still stored in the form and can be viewed by any user that knows how to download.
• Difficult to integrate with Forms-Based Authentication
  Although browser-enabled forms will work with forms-based authentication, the useful username() function no longer works.  This means that even if you’re logged into your SharePoint site as a valid FBA user, InfoPath will have no idea who you are.
• Not developer-friendly
  If you’ve made it this far in this post, you’ll have already read that while simple things are easy to accomplish in InfoPath, complicated things aren’t and often requires .NET code.  While you can definitely add .NET code to a form, it’s not the same type of form coding a typical developer is used to.  You have to parse XML to retrieve field values, you have to parse XML to set field values, and you’re still pretty much limited to the functionality that you have through the designer.  You can just write more complex business rules and logic, you can’t make the form or the field controls behave any differently.
• Licensing
  Obviously your users need to be licensed for InfoPath Forms Services before they’re able to use it. Even if you have licenses for the InfoPath client, separate licenses are required for browser forms. If the users are internal and members of your domain, you must be licensed for InfoPath Forms Services, which is available either through the MOSS Enterprise CAL or the standalone InfoPath Forms Services CAL.  If the forms are going to be available externally to non-domain users or anonymous users, then you must be licensed for either Office Forms Services for Internet Sites or be licensed for SharePoint for Internet Sites, which is the external connector that provides the ability for an unlimited number of users to access and use InfoPath through a browser.

ASP.NET ASPX Forms
Creating ASP.NET ASPX forms offer the most in terms of flexibility, as you can do anything that you can do in a traditional ASP.NET web site, including HTML, CSS, JavaScript, and even AJAX.  A lesser-known technique is integrating these pages into the SharePoint “shell” to give users a seamless experience.  It doesn’t take much effort to have SharePoint host these pages and have the master page and styles applied to your custom forms.  Let’s take a look at some pros and cons associated with ASP.NET forms:

Pros

• Great for submitting data to non-SharePoint data sources
  While InfoPath is great at submitting data to a SharePoint form library, ASP.NET forms are great for submitting data to everything else.  You can easily write your ADO.NET code or whatever-you-like code to submit to your data source, and not have to worry about parsing a bunch of InfoPath XML first in order to pull out the values.  It’s a lot less work to get the data into your data source.
• Great for providing a rich user interface
  Unlike InfoPath, you aren’t limited to a tiny set of field controls.  You can use whatever an ASP.NET web site supports, including tree view, tab controls, grid views, AJAX – even Silverlight if you really really want.  You can also provide any type of business rules and validation you like as well, including summaries, friendly pop ups, etc.  Also, since the pages are inheriting the SharePoint styles and master page, your forms will automatically pick these styles up, and will also use the master page.  This gives the appearance that they’re actually built-in SharePoint pages.  It’s slick. There are plenty more options for developing a rich and clean user interface if you’re developing ASP.NET forms.
• Developer friendly
  This one’s a no-brainer.  Obviously if you’re familiar with ASP.NET and .NET programming, creating data-entry forms are a cinch.  There’s no learning curve with learning how to code an InfoPath form, and you don’t have to learn the ins and outs of the InfoPath object model.  This opens up the development work to a wider audience of our developers, as not many have hands-on experience with writing .NET code behind an InfoPath form.  In addition, should any future updates be required to the form or the code, finding resources on ASP.NET online or hiring someone with ASP.NET skills will not be a difficult task.  It’s a widely practiced technology, and there are a ton of resources.
• Can provide secure means of sensitive data access
  Since no data is actually stored in the ASP.NET form, it provides a much more secure way of viewing sensitive data, as it will have to be retrieved and submitted to the database directly.  A user can’t download an ASP.NET form and see the data like they can with an InfoPath form.
• Integrates well with Forms-Based Authentication
  By using an ASP.NET form in an FBA-enabled site, we are able to see the user that is currently logged in, unlike with an InfoPath form.
• Access to the SharePoint Object Model
  Since the ASP.NET forms are running under the context of the SharePoint site they’re accessed from, we can use the SharePoint Object Model to do whatever we wanted.  We could very easily access SharePoint list or site data, user profile information, etc., and bind that information to controls on the form.  To do this in InfoPath, you’d have to use the unfriendly out-of-the-box SharePoint web services, or write your own.
• Licensing
  Not required! There aren’t any licensing headaches when exposing ASP.NET forms to users, even externally.  Obviously since they’re going to be integrated into SharePoint, you’ll have to have the appropriate licenses for that, but nothing specific to the forms themselves.

Cons

• Potential additional development overhead
  Obviously writing custom ASP.NET forms requires a competent ASP.NET developer, which may not always be available (though I’d argue that in order to develop some of the complex forms that we have had to do in the past – you will still need a very competent .NET developer).  In addition, changes to simple business rules or data validation is more difficult to accomplish in ASP.NET than in an InfoPath form.  If the form is simple and doesn’t require data going to SQL, then an end-user is probably better of just using InfoPath.
• Requires file system access on SharePoint server
  To deploy custom ASP.NET forms to SharePoint, they need to be placed onto each web front-end’s file system.  In addition, the assembly must be deployed to the GAC or to the web site root’s BIN directory.  Either way, the developer must have access to the file system, or to someone that has access to the file system.
• Not business-user friendly
  One good thing about InfoPath is that business users can even build simple forms.  They will probably not be able to develop an ASP.NET form in .NET.  If the form is truly that simple, then creating ASP.NET forms is probably overkill anyways, and InfoPath should be the recommended solution.

So, How Do I Choose?
Great question! The answer should be easy -- do the simplest thing possible that will result in a clean solution.  If you can implement the desired functionality quickly and painlessly in an InfoPath form, then by all means do that.  If developing an InfoPath will actually be prohibitive to functionality and future maintainability, then consider building custom ASP.NET forms.

To make your decision even easier, I built a flowchart that should help guide you.  It does not include every scenario, but does include most scenarios that we deal with:

 

Conclusion
Hopefully this post ironed out some of the confusion surrounding what solution to offer clients for their electronic forms requirements.  In no way should we suggest InfoPath just because “it’s an Office app that integrates nicely with SharePoint”.  In some cases it does, it many cases it does not.  The actual requirements need to be evaluated before jumping on the InfoPath bandwagon.  Trust me, I’ve had my hands in enough complex InfoPath forms, and I know that after a certain point of complexity, doing something in InfoPath is more difficult, more expensive, and plenty more aggravating. InfoPath is merely a mechanism to get data into SharePoint. It should not be used to develop complex data entry forms when the data is going to a non-SharePoint data source.  It’s like trying to make a spoon behave like a Swiss Army knife.  Understand what it does well, and more importantly understand what it does not.