I am maybe one of the first to work with a team that is developing an
enterprise application using C#, SQL Server, SharePoint, and InfoPath for
the user interface.
From my experience, InfoPath is an office application, for the end user to
develop a simple form without coding, or with minimum coding. And to store
their data as xml files in SharePoint, and perhaps the small forms to a
database.
There is software that "may work" with InfoPath providing it with workflow
and document transformations (BizTalk 2004), but connecting that software to
an enterprise form requites at least a month of development, and perhaps a
c# code (to store and load a large form from and to a database) (if you ever
pass the difficulties of connecting them first).
It also maybe used by C# developers, with the new toolkit, but they actually
will use the java script xml DOM wrapped to c#, not the System.XML, although
they are similar a bit once you get used to them.
InfoPath is fine if you are loading and saving your forms from and to
SharePoint as XML, you can build an application this way easily (and very
fast, with minimum resources), but remember, the data mining at this stage
is very limited, not like the database, but if you don't need it, you are
just fine.
In my application, SharePoint is showing data from a database, once the end
user clicks on an item, an InfoPath form will open, getting its data from
the database too, using a web service that is converting it to xml.
In out project we started as 2 developers, then realized after 2 months of
connecting BizTalk to InfoPath 2003 SP1 beta, that is almost impossible to
use them together (in our scenario), then we hired more developers to build
the server side (without BizTalk of course), and the server side is working
fine now, but the amount of development needed just to make these forms
working correctly was scary, you have an entire new layer, the
transformation layer (totally unnecessary from my point of view, but
InfoPath can't live without it); You will be loading and storing huge
amounts of xml from and to InfoPath (just because the form cannot work with
multiple database datasets).
And today we are realizing that the speed of the application is
unsatisfying, the end user requires a response not less than 3 seconds,
there is no way for InfoPath to load it (not open) in this time (when you
are getting it from the web server) in our best tests, the form loads in 7
seconds, and gets its data in 3 seconds (huge amount of data tables
converted to xml), then 5 seconds formatting itself on the screen.
Now I am thinking, if I used ASP.NET with custom controls, to achieve the
repeating tables and the rich text boxes, the same form may render itself on
the screen in 1 and a half second (on the multi processor server that we
have), and another second to load the data from the database without all
these unnecessary DB <-> XML transformations, and I am realizing if I used
Windows Forms connected to the server using .NET Remoting (in the middle
layer) and then connected using ADO.NET to the database, the timing would
have been instant.
At the end it is up to you, some projects will just work fine if you are
using InfoPath; some other will not, research the product first, and have a
look at it when it is required to work under heavy pressure (large form,
multiple nested sections, a lot of event handlers, conditional formatting,
etc.)
I think if the next office has something like an Office Explorer, or
Internet Explorer+, something that can cash the forms during your visit to a
SharePoint site, may improve the performance a lot, loading and compiling,
etc.
Good luck
