Making a web page to perform as you have to, is possible in multiple ways, and of course, the implementation can vary heavily based on the minor requests to implement.
However, one of the important things to remember, verify and control is the behavior of the page when doing the postback, and here you have two keys aspects: the UpdateOnPostBack property of the AxForm / AxGrid and the AutoPostBack of the controls (be that an ax databound control or asp.net controls). This will basically control how (or better said when) you want the code to perform automatic updates.
If you set the UpdateOnPostBack to true this will cause the datasource to automatically update the record on the postback. Also, setting AutoPostBack to true on a control will cause the page to do a postback. At this point in time, the datasource's record will update itself. Now, this works just fine when the Ax DataSet has one DataSource, but it become troublesome if there are multiple datasources, join (inner or outer) - not saying that this doesn't work, but normally the amount of functionality to control in this case is of a greater complexity.
So, from my experience I consider it is better to disable the automatic updates provided by the framework in a complex scenario and try to handle the writes (insert/update) from code. You will notice that sometime also in the standard code, the write method of the datasource is overridden and the super call is commented out - this is done sometimes with the UpdateOnPostBack set to true, but this is exactly for a better control of how or when the data is written.
The items to take into account are: the life cycle page, the types of the joins and the way the datasources joins are affecting the overall life cycle, the type of operation (is it an insert or update?).