The XmlFormView is a common way to display Office InfoPath 2007 browser forms on a custom ASPX page. Microsoft published a great technical article a while back about how to use the XmlFormView control to host the InfoPath editing environment, and we use it frequently in our InfoPath Forms Services solutions.
One thing to keep in mind though, which the article does mention, is that the InfoPath form template that is to be displayed in the XmlFormView control must reside in the same site collection as the custom ASPX page. In other words, if you have a Web application with a site URL of https://www.microsoft.com/en-us/ and your form template has been admin-deployed or published directly to a Web application with a site URL of https://www.microsoft.com/en-us/, then that form cannot be hosted on a Web page within the https://www.microsoft.com/en-us/ site collection.
Continuing with this example, the solution to the problem is quite simple if the form template was admin-deployed to the https://www.microsoft.com/en-us/ site collection. There are no restrictions imposed by InfoPath Forms Services about the number of site collections to which you can activate your form template. So, assuming data connections in your form template have been managed correctly (a topic for another day), then you can simply activate the form template to the https://www.microsoft.com/en-us/ site collection. Then, with the XmlFormView control selected in your custom ASPX page in Visual Studio, you can set the XsnLocation property to the relative location of the form template within the site collection.