And one more update of
the popular support topic, but quite advanced, though. Anyway, here we go:
Take special note that this is a specific and non-standard use-case scenario, which is not intentionally supported and tested by us internally. By default, many application modules rely on the XAF infrastructure and cannot be used outside it without special initialization or boilerplate code, which is usually created in the default XAF project templates created by the XAF Solution Wizard (see the YourSolutionName.Win/Program.xx orYourSolutionName.Web/Global.asax.xx files for more details). At the moment, most functionality of UI modules available to end-users is supposed to work in the client XAF WinForms, ASP.NET Web Forms and Mobile apps. For instance, you cannot have an arbitrary XAF DetailView embedded into your non-XAF ASP.NET MVC or WinForms app without much preparation (see the example below for more details) or at all with all the standard XAF functionality included.
Even though there are also non-visual XAF core components that can be reused in non-XAF apps with less effort (e.g., our security, audit and validation engines), they still require implementing custom-tailored solutions and a special initialization manually in your non-XAF app. Finally, since we do not test such scenarios internally, we do not guarantee normal operation of all XAF components in non-XAF apps. Depending on the module and target use scenario, there may be nuances and you must carefully test these scenarios or may probably be required to write additional code to get it working according to your business needs. For instance, since many standard modules (security, validation, reports, etc.) depend on the XafApplication.LoggedOn event or the activation of controllers for the main application window to perform their initialization, you may need to replicate the same circumstances in your non-XAF app if you want to make use of dependent functions. Also, if you're developing a Windows Forms app, it must be single-threaded (STA) by design, so you cannot easily invoke the standard XAF WinForms functionality in threads other than the main one.
On the other hand, it is important to note that in a well-designed and structured application, it is also not difficult to separate and reuse the ORM data model or business classes, which are normally not tied to the visual or UI parts. Very often, it is the best practice to have a single common or shared class library for your persistent classes, which may not have any XAF dependencies. This way, to use persistent objects in non-XAF applications and services, it is sufficient to add a reference to this shared assembly and then follow your ORM documentation (e.g., XPO) to learn more on how to set up database connection, create, query, delete persistent objects.
