In the manager templates there are overloads for passing IDataAccessAdapter objects into methods.

I was under the impression that these overloads were for special cases when methods in different controllers needed to share the data access adapter for transaction purposes.

Couldnt the same result be acheived by using a UnitOfWork object? Do all objects nested in a UoW commit in the same transaction?

The reason that I ask, is because in my manager classes, the objects are statefule, i.e. you need an instance of the manager to work with it. All methods that take IDataAccessAdapters as arguments are marked as protected, and I have added the code to my ManagerBase class template:

        public void CommitUnitOfWork(UnitOfWork2 uow)
        {
            CommitUnitOfWork(uow,true);
        }

        public virtual void CommitUnitOfWork(UnitOfWork2 uow, bool autoCommit)
        {
            using (DataAccessAdapter adapter = new DataAccessAdapter())
            {
                uow.Commit(adapter, autoCommit);
            }
        }

The reason that I made my manager classes stateful is so that I could use them within the realm of COM+ when I need to. I also made the methods that provide IDataAccessAdapter arguments protected because my stance is that 1. consumers of the managers are gui developers, and 2. gui developers dont need to muck with the data source.

Am I shooting myself in the foot here?

So when a gui developer codes for my framework, they end up writing code similar to this:

                ControllerBase controller = ControllerFactory.GetController(
                    ModuleSettingsController.ModuleSettingsControllerKey);

                EntityCollection moduleDataToSave = new EntityCollection(
                    new ModuleSettingsEntityFactory());

                moduleDataToSave.Add(SurveyClosingDateSetting(closingDate));
                moduleDataToSave.Add(SurveyTrackingSetting());
                moduleDataToSave.Add(SurveyResultTypeSetting());


                UnitOfWork2 uow = new UnitOfWork2();
                uow.AddCollectionForSave(moduleDataToSave);
                uow.AddForSave(SurveyGraphWidthSetting());

                controller.CommitUnitOfWork(uow,true);

The controller class is the manager class. The unit of work is saving various items.

Devildog74 wrote:

In the manager templates there are overloads for passing IDataAccessAdapter objects into methods.

I was under the impression that these overloads were for special cases when methods in different controllers needed to share the data access adapter for transaction purposes.

Couldnt the same result be acheived by using a UnitOfWork object? Do all objects nested in a UoW commit in the same transaction?

Yes.

The reason that I ask, is because in my manager classes, the objects are statefule, i.e. you need an instance of the manager to work with it. All methods that take IDataAccessAdapters as arguments are marked as protected, and I have added the code to my ManagerBase class template:

        public void CommitUnitOfWork(UnitOfWork2 uow)
        {
            CommitUnitOfWork(uow,true);
        }

        public virtual void CommitUnitOfWork(UnitOfWork2 uow, bool autoCommit)
        {
            using (DataAccessAdapter adapter = new DataAccessAdapter())
            {
                uow.Commit(adapter, autoCommit);
            }
        }

The reason that I made my manager classes stateful is so that I could use them within the realm of COM+ when I need to.

Doesn't COM+ require you to write stateLESS objects? (or isn't that required for enterprise services anymore?)

I also made the methods that provide IDataAccessAdapter arguments protected because my stance is that 1. consumers of the managers are gui developers, and 2. gui developers dont need to muck with the data source.

Am I shooting myself in the foot here?

No I don't think it's a big problem. Let me use an example from the .NET Petshop example . In there I had to save orders and manage the inventory. I didn't want to re-design the app, so I re-used classes already there. The problem was that I had to pass on a data-access adapter object to the inventory manager to make those changes run in the same transaction.

So internally, in the BL / manager assembly, the adapter was passed on, the gui doesnt know nor care, it just calls the order manager.

So when a gui developer codes for my framework, they end up writing code similar to this:

                ControllerBase controller = ControllerFactory.GetController(
                    ModuleSettingsController.ModuleSettingsControllerKey);

                EntityCollection moduleDataToSave = new EntityCollection(
                    new ModuleSettingsEntityFactory());

                moduleDataToSave.Add(SurveyClosingDateSetting(closingDate));
                moduleDataToSave.Add(SurveyTrackingSetting());
                moduleDataToSave.Add(SurveyResultTypeSetting());


                UnitOfWork2 uow = new UnitOfWork2();
                uow.AddCollectionForSave(moduleDataToSave);
                uow.AddForSave(SurveyGraphWidthSetting());

                controller.CommitUnitOfWork(uow,true);

The controller class is the manager class. The unit of work is saving various items.

I think that's a good usage The UoW solves you from passing around DataAccessAdapters indeed. In the case where you have to target multiple databases, you can of course use multiple UoW's.

Frans, thanks for the input.

I dont have issues with framework developers passing around data access adapters, I just want those methods hidden from the gui code, and I have acheived that using the protected methods in ManagerBase and EntityManagerBase.

Anyhow, thanks for the sanity check.