I am designing a complete set of DotNetNuke modules for an organization. The modules would totally abstract the end-users from DNN Administration tasks like Role or User Management, as these tasks are to be performed implicitly as the result of user actions on a module.
e.g. When a user creates an organizational department on one of the modules, a Role needs to be automatically created for that department, and all members of that department be assigned to that module.

The task itself is not too complex. I create a department through my Data Layer, and can create a Role for it through the DNN Provider.

The problem arises when considering the fact that these actions need to be performed inside a transaction. If department is created, but for some reason, the Role API cannot create the role, the Department creation needs to be rolled back.

So, what is the best practise solution in this regard??? Should I implement the transaction in the Business Logic class, which calls 2 methods in DAL (one for creating department, and the other for creating Role) or in the Data Access class, which creates the Department & role in one go???

Also, can I in some way make the DNN Role API's method for creating the Role execute as part of a transaction initiated in my BL or DAL layer, or would I need to rewrite that method in my DAL???

You're best bet for DNN questions is to use the dedicated DNN forums at: http://www.dotnetnuke.com/tabid/795/Default.aspx.

 

 Apa

mbanavige:

You're best bet for DNN questions is to use the dedicated DNN forums at: http://www.dotnetnuke.com/tabid/795/Default.aspx.

 

Apart from obvious relationship to DNN, this question was also regarding larger Application Design, as to how Transactions fit in the design of an Application (particularly an Application architected on the lines of the ASP.NET 2.0 Provider Model).

My prrior experience in implementing transactions at a mix of BLL & DAL does not leave me very satisfied!!!

Supposing I have to call multiple Stored Procedures for a task that have to be executed inside a transaction, one of which creates a Department entry, and the other a Role for that department, then from a best practices perspective, what is advisable?

1) I create a separate method in the DAL that call the SP to create the role. Then, have my BL class call the methods for creating department & then the Role one after the another. In that case, the BL would need to be aware of the underlying transaction in some way, and would need to request the DAL to commit, if everything is fine.

2) Have my DAL method to create the department perform 2 operations: i) Create department, and then ii) Create Role. In this case, the BL would be totally abstracted from the underlying trasanction, as the DAL can itself decide when to commit or abort.

To me, although the second approach seems more attractive from an implementation point, but logically, the method for creating department should only do that. It is the BL that knows, that creation of department should be followed by creation of a role for that department!!!