I managed to do this with some success in CSLA 1.x. The main problem is with reflection, which CSLA obviously uses a lot of, and there may be other things such as remoting and serialization.
The two main areas to avoid are n-level undo and the DataPortal, both of which
make heavy use of reflection.
Avoiding n-level undo is easy, and this is almost never used in web environments
anyway, so just don't call BeginEdit.
To avoid the DataPortal, I found the easiest thing to do is just call your
DataPortal_XYZ methods directly from the Shared Factory methods. So instead of
:
Public Shared Function GetMyBO As BO
Return CType(DataPortal.Fetch(New Criteria()),BO)
End Function
You would do something like:
Public Shared Function GetMyBO As BO
Dim myBO as New BO ' use of the private constructor is fine as we're in the
class
myBO.DataPortal_Fetch(New Criteria())
Return myBO
End Function
At least I think that's how I did it (writing from memory)
The other approach would be to go through the framework and remove any of the
n-level undo/ reflection parts, but that just becomes too painful and makes
life really hard to include new updates etc.
hth,
Dan.
boo:
Yes, this does help very much. Thanks! The size of this project, and being on a shared host, it will never be remoted so there's not much need to go through the DataPortal in this light. Will this cause problems though when using the CheckRules() and other validation/authorization methods?
Rocky, have you ever considered creating a light version build for scenerio's such as this? I know that's extra burden for you...but I got to ask. :)
![Big Smile [:D]](/emoticons/emotion-2.gif)
boo,
>>I should be given Admin powers so I can do anything I want :)
I've had similar needs before, albeit not because of CSLA, but because of other stuff we decided to base our architecture on. Although more expensive, you can get folks to host dedicated servers that will do whatever you want. When we looked into the costs, it made more sense to host it ourselves.
Just a thought,
Mike
Rocky
If a lightweight version of CSLA.NET that would work in partial trust environments was produced by contributors to CSLA would you sanction this work and maybe include some of the code that was required in the primary branch(es)?
Would you provide some initial guidance and mentoring regarding this project without actually doing any of the work or subsequent testing yourself?
Could this be done simply with preprocessor directives and a seperate project excluding the files that are not required or am I being a bit simplistic?
Regards
Tim
I am not interested in having a fork of CSLA, no. The closest I've ever come to this, is when Lawerence built the CF version a few years ago, and he donated it to the public (it is in my svn server).
However, I'm perfectly happy to have contributors to the actual CSLA project that work toward this goal within the mainstream codebase. And honestly, it wouldn't be that hard now, because the SL/WP7 codebase is extremely close to what you'd need - and for the most part it is the mainstream codebase with a few compiler directives.
Or to put it another way, the biggest problem with partial trust is the use of the BinaryFormatter or NetDataContractSerializer. Since we wrote the MobileFormatter to support SL, the solution already exists. Mostly what is needed is to enhance the serializer selector in Csla.Serialization to allow the use of MobileFormatter in .NET too and the single biggest issue for partial trust would go away.
I suspect there are some things in MethodCaller too, where some config-based abstraction would be required - basically allow the efficient fulltrust code to run normally, but via config you could opt to use the same code used on SL.
I guess what I'm saying, is that (thanks to SL) most of the hard work to run outside fulltrust was done about 3 years ago. The effort now would be to make those code paths available to .NET code (optionally - most of them aren't as efficient as the fulltrust counterparts) so you could opt into that mode when necessary.
We certainly don't need another project or set of Csla.dll files. There should be no reason that'd be required.
Rocky
Thanks for response, I don't envy the task of looking after one version of CSLA let alone three or four so I understand your response and agree completey.
I think that providing this functionality would be an important and popular upgrade to CSLA.NET. It is a shame not to have the same (or nearly the same) features and functionality available to Hosted Web Developers as well as those in fully trusted environments. I think the hit on performance and restrictions in feature set is probably a compromise must of us would be willing to accept for the use of the feature rich, easy to use framework we know and love!
Could this be retrofitted into 3.8.X as well or would it only appear in 4.0.X?
Please let me know if I can assist in testing or development work on this.
Thanks again
Tim
That depends on how much work someone (you? :) ) is willing to do.
Generally I view 3.8.4 as purely in maintenance mode. I have zero plans to enhance 3.8, or even fix anything but the most important bugs.
I think it would be a little harder to make 3.8 work in partial trust too, because it is one assembly, where as CSLA 4 is split into multiple assemblies. I'm not entirely sure how you'd handle the Windows Forms or WPF code - or maybe that wouldn't matter because it would never be loaded by the type loader?
In any case, if I ultimately do this it would be only for CSLA 4. If someone else does it, I could be persuaded to allow a 3.8.5 that would include this enhancement to 3.8.
Ok Rocky, I will assign some time to take a look at this and get back to you.
Reason why I am looking 3.8.X is that not everyone has upgraded to VS2010 yet (including me) 
Thanks for your responses.
Regards
Tim
To become a contributor you'll need to sign a contributor agreement. Email me directly (rocky at lhotka dot net) and I'll get you the agreement to review, etc.
Copyright (c) Marimer LLC