On vacation
I’m on vacation.
I have a lot to do once I get back but right now I’m trying hard not to think about it.
I have some really good music and books with me.
And, for the first time in years, I don’t have my laptop with me.
It feels great!
I’m on vacation.
I have a lot to do once I get back but right now I’m trying hard not to think about it.
I have some really good music and books with me.
And, for the first time in years, I don’t have my laptop with me.
It feels great!
Mackie wrote:
I am in the process of incorporating WF into my asp.net application. A lot of the asp.net/wf sample applications, I am repeatedly seeing examples using a caching mechanism to store the workflow runtime instance. I am a bit perplexed by this. There seems to be a glaring limitation to this approach which hinges on the idea of modularity. By that I mean a workflow implementation that is unaware of its hosting environment.
For example why could I not do the following and not have to depend on caching and the realization that I exist in an asp.net world. This would also solve the problem of not depending on application_init to make the initial call to initialize the WorkflowRuntime instance and can be called from anywhere.
public sealed class WorkflowRuntimeManager
{
private static WorkflowRuntimeManager _instance = null;
private static WorkflowRuntime _workflowRuntime = null;
private static object _lock = new object();
///
///
///
public static WorkflowRuntimeManager Instance
{
get
{
if (_instance == null) {
lock (_lock) {
if (_instance == null) {
_instance = new WorkflowRuntimeManager();
_workflowRuntime = new WorkflowRuntime();
}
}
}
return _instance;
}
}
///
///
///
public WorkflowRuntime WorkflowRuntime
{
get { return _workflowRuntime; }
}
}
I can now make the call WorkflowRuntime wfRuntime = WorkflowRuntimeManager.Instance.WorkflowRuntime;
I am guaranteed to get one instance of the WorkflowRuntime and I do not have to depend on any caching mechanism to store the workflow runtime instance. By doing this, I can now create a reusable workflow runtime component to perform workflow and workflow management that is unaware of its hosting environment. As an example I can have CompanyName.Core.Workflow which can now be used across all application domains be they win apps, win services or asp.net apps. Is there a reason why this runtime initialization is omitted?
Thanks,
-Mackie
Posted on 03-Dec-06 at 11:53 pm | Permalink
Dmitriy Andreyev wrote:
Hello dear Dharma Shukla.
My name is Dmitriy. I am Russian software engineer. I am sorry for my English.
Some years your article ” Extending ATL 3.0 Control Containment to Help You Write Real-world Containers “, an example to it “VBLite”, and source of classes from http://members.tripod.com/IIUnknwn, etc, are for me a guide on creation COM components. Thanking it I have learned to create a browsable properties of component, with the help of ICategorizeProperties and IPerPropertyBrowsing. But it is browsing as Combo Box or expand and collapse only on the tab “Categorized”, on the tab “Alphabetical” isn’t. Besides this method is necessary to describe a COM_MAP of properties in the itself ActiveX control.
However by development of difficult projects it is required, that interfaces responded on Visual Studio IDE queries and provided expanding and collapsing hierarchy of interfaces. I know, that you now are engaged in a .Net, but there can be you recollect and will prompt as to create in Visual C++ own COM component with a few properties, like a IFont, that it could be implemented in the ActiveX controls. And so as to properties this component will be browsable in a Properties ActiveX Control in IDE Visual Studio 2005 (as a properties of IFontDisp).
This problem is solved in the .Net (MSDN > “Make Your Components Really RAD with Visual Studio .NET Property Browser”), but it would be desirable to know the decision of this problem with the help of ATL.
Beforehand I thank, you for the rendered help.
mailto: adl967@mail.ru
Posted on 07-Nov-07 at 8:14 am | Permalink