Server-side DataPortal enhancement

Server-side DataPortal enhancement

Old forum URL:

chachek posted on Tuesday, May 19, 2009

Could it be possible for the DataPortalSelector to not only decide between the SimpleDataPortal and the FactoryDataPortal, but also take a class that implements IDataPortalServer given at runtime (via configuration perhaps)....I think this would provide maximum flexibility on the "logical" server side.

just a suggestion....

thanks for a great framework!!

RockfordLhotka replied on Tuesday, May 19, 2009

It could do this, yes. But I try to only add features, especially ones like this, that expand the testing and support surface of the framework, when there's a clear and pressing need for such a change.

Do you have a scenario where the current two data access models are insufficient?

The DataPortal_XYZ is (more or less) active record. And the object factory enables a data mapper pattern. I think either of them can be used with the repository pattern, though that is probably a lot easier with the object factory approach.

That pretty much covers the current trendy DAL patterns, but I'm always open to discussion around scenarios that might be compelling.

chachek replied on Tuesday, May 19, 2009

The only issue that I have right now is the use of TransactionScope. It seems that in certain situations Oracle doesn't know how to handle it, specifically when using DB links (long story).

I still want to have my root object define my transaction scope, but can not use your Transactional attribute. Right now I'm working around the issue by committing the transaction on DataPortal_OnDataPortalInvokeComplete and rolling back on DataPortal_OnDataPortalException on my base classes. The ideal would be to have something similar to TransactionScope and use it in my own implementation of IDataPortalServer.

That's my scenario but I understand that you have to keep the framework "lean & mean" and above all maintainable.


RockfordLhotka replied on Tuesday, May 19, 2009

This scenario wouldn’t be served by opening the selector then. The transaction mode is set before the selector is invoked. The server-side data portal is actually a pipeline that goes through several steps – which is necessary because in the Enterprise Services option the data portal has to actually get your code running inside a COM+ object.


If you want transactional support for Oracle, you might consider using Enterprise Services (COM+). As I understand it, Oracle has worked with the distributed transaction standards used by COM+ for a very long time, and you might have better luck.


I wouldn’t use the InvokeComplete/Exception methods as you describe in any case. Instead, I’d contain all transaction management in the DataPortal_XYZ method (insert/update/deleteself/delete). That keeps things more concise.


You might also look at the Csla.Data.TransactionManager class to see if it can help you. It is designed to simplify the use of ADO.NET transaction objects when using the manual transaction option.



From a “change the data portal” viewpoint, what you really need/want is to be able to provide your own object to manage the data portal transaction instead of using the three models currently supported. The only trick there, is that the Transactional attribute is not currently capable of expressing arbitrary transaction types. I could add “Custom” to the list, but then someone would come along and say they need multiple custom options or something…



Copyright (c) Marimer LLC