I want to provide my own implementation of TimerExtention in place of DurableTimerExtention provided by Delay activity, so that I can test workflows that use delays.
How can I accomplish that?
I have WorkflowService instance and its root Activity. The workflow service is hosted in WorkflowServiceHost, (though I can not figure out how to get WorkflowInstance instance)
One way to test your workflows is to use the Microsoft.Activities.UnitTesting on CodePlex. It has the capability to mock activities using XAML Injection. See here for more details.
In the case of a Delay activity you can do things a lot simpler though. Instead of hard coding the Duration to a fixed value I normally create a config object with the duration in there. In the Delay activity I just enter an expression like Settings.WaitForPaymentDuration. In production the Settings.WaitForPaymentDuration will be set to something like 30 days but in a test I can set it to 1 second instead without changing the workflow at all.
I have had a similar interest in mocking the TimerExtension, I wrote a blog post about it. In that post I inject my own implementation of the TimerExtension using WorkflowApplication.Extensions.Add<T>(Func<T>). WorkflowServiceHost also has this collection. You could replace the concrete class I have in my example with a mock. I wrote it targeting 4.5, but it should work with anything that uses the Extension collection. Its in 4, not sure earlier versions.
[Link]
Related
I found many languages provides some way to change code runtime. Many people ask queries regarding how to change code in this or that language runtime. Here I mean by change code is that rewrite code itself at runtime by using reflection or something else.
I have around 6 year of experience in Java application development. I never come again any problem where I have to change code at time.
Can anyone explain why we require to change code at runtime?
I have experienced three huge benefits of changing code at runtime:
Fixing bugs in a production environment without shutting down the application server. This allowed us to fix bugs on just some part of the application without interrupting the whole system.
Possibility of changing the business rule without having to deploy a new version of the application. A quicker deploy of features.
Writing unit test is easier. For example, you can mock dependencies, add some desired behaviour to some objects and etc. Spock Framework does well this.
Of course, we had this benefits because we have a very well defined development process on how to proceed on this situations.
At times you may need to call a method based on the input, that was received earlier in the program.
It could be used for dynamic calculation of value based on the key index, where every key is calculated in a different way or calculation requires fetching required data from different sources. Instead of using switch statement you can invoke a method dynamically using methodName+indexOfTheKey.
In one of my views, I have a ViewModel which I populate from two tables, and then bind a List<ViewModel> to an editable GridView (ASP.NET Web Forms).
Now I need to send that edited List<ViewModel> back to the Services layer to update it in the database.
My question is - is it Okay to send the ViewModel back to Services, or should it stay in the Presentation? If not - should I better use a DTO? Many thanks.
Nice question !
After several (hard) debates with my teammates + my experience with MVC applications, I would not recommend to pass viewmodel to your service / domain layer.
ViewModel belongs to presentation, no matter what.
Because viewModel can be a combination of different models (e.g : 1 viewModel built from 10 models), your service layer should only work with your domain entities.
Otherwise, your service layer will end up to be unusable because constrained by your viewModels which are specifics for one view.
Nice tools like https://github.com/AutoMapper/AutoMapper were made to make the mapping job.
I would not do it. My rule is: supply service methods with everything they need to do their job and nothing more.
Why?
Because it reduces coupling. More often than not service methods are addressed from several sources (consumers). It is much easier for a consumer to fulfil a simple method signature than having to build a relatively complex object like a view model that it otherwise may have nothing to do with. It may even need a reference to an assembly it wouldn't need otherwise.
It greatly reduces maintenance effort. I think an average developer spends more than 50% of his time inspecting and tracking existing code (maybe even much more). Now everybody knows that looking for something that is not there takes disproportionally much time: you must have been everywhere to be sure. If a method receives arguments (or object with properties) that are not used directly or further down the call stack you or others will walk this long road time and again.
So if there is anything in the view model that does not play a part in the service method, don't use it to call the method.
Yes. I am pretty sure it is ok.
Try to use MS Entity Framework and it will help you allots.
I have a custom implementation of a multi tenant code first system basically SQL Schema Divisions of the tenants. I am using the ToTable method to map the schema correctly on the first call, but as I have read about the model being cached changing the schema on the second call do a different tenant does not work. Is there any ways in EF 4.1 to disable the caching or to rebuild the model every time.. Yes i know this is not great for performance. Thanks for any help..
Although it is an old question, but for all those who face this issue and end up finding this question for a possible solution. Here it goes...
Initially caching could be turned off by setting the "CacheForContextType" property of the ModelBuilder to ‘false’ in the OnModelCreating method. This method is defined in DBContext as virtual and needs to be overridden. But in EF 4.1 this property has been removed, since model creation is an expensive process and the Microsoft team wanted to promote a better pattern. Check this link
It seems like the Build() command on the ModelBuilder is what you're looking for.
modelBuilder.Build().Compile().CreateObjectContext...
I have been working in an MVC project, and have seen both of these used. I was wondering what the difference between them is? Is it incorrect to use one over the other? My understanding is that I should be using Url.Content(), but VirtualPathUtility.ToAbsolute() seems to be working as well.
Url.Content() is an utility method part of MVC. Being there to uniformize and centralize utility classes I guess.
VirtualPathUtility.ToAbsolute() is a .NET Framework method. Maybe the MVC one is using it, we would have to check the source...
Hope the helps
If you are doing this conversion within a Controller, then I'd favour VirtualParthUtility.ToAbsolute() over Url.Content().
The benefit comes when you want to unit test the controller actions. Rather than call it directly though, I'd define an interface IPathUtilities, say, with one implementation using VirtualPathUtility methods for the live site, and another using some sort of mock when testing.
If you call VirtualPathUtility directly, then you won't be able to test the action method (you might have thought some clever mocking of HttpContext would get round this, but having tried this myself I couldn't find a way to do it).
I am working on a design spec for a new application that will be heavily workflow driven.
Before I re-invent the wheel, is there a decent lightweight workflow engine that plugs into ASP.NET already around?
Basically, I'm looking for something that handles moving through a defined set of workflow pages while handling state management automatically.
If this isn't around already, I'll definitely try to abstract the engine from my app and put it on codeplex, as it would be really handy.
Any suggestions?
Note: .NET 2.0, so no WWF, though I think WWF is overkill for my needs.
EDIT: Seems like there is a legitimate need for this, and there isn't a product out there...So I might build this.
Here is what I'm picturing:
Custom Page class called WebFlowPage
All WebFlowPage's are registered in a Workflow mapper.
Each WebFlowPage has some form of state object.
A HttpHandler handles picking the appropriate WebFlowPage based upon the workflow, and populating it from the state object.
Is the workflow dynamic, or static?
If the workflows are simple, you could roll your own workflow engine.
In certain situations, it can be fairly simple, and just a couple of data tables to handle the rules, processing and state.
Alot of workflow engines are built for large scale processing (credit card applications, for example). For small scale, you should at least consider your own, which would eliminate the overhead and dependency of/on an engine.
Not sure exactly what you wish to do here, but Ra-Ajax can easily keep state at least if you want your solution ajaxified...
For reference purposes you might want to check out the Ajax Calendar sample or even the (banalistically implemented) Ajax Wizard sample. It surely beats the hell out of doing it with JavaScript...
And every time you "do something" you're in "server-land" which means you can store temporaries all the time as you wish...
The project is LGPL
(PS!
Yes I do work with it)
Building a custom workflow engine is not trivial, although it may seem simple at first. We've tried that. It depends a lot on the complexity of the logic you need it to cover.
Given the current state of the Windows Workflow Foundation and the lack of another framework that abstracts the workflow concepts, I would choose WF if you need complex logic, asynchronous handling or branches in your workflows.
Tracking your state through the workflow can be accomplished by carrying some kind of xml payload or storing the state in a database,
If your workflow is actually a sequential set of forms that need to be filled in by the user, tracking the steps and guiding the user to the next step can be accomplished with some simple custom solution.
You could take a look at the InRule engine too.
Also, there is nxBRE.
These too are mostly used for business rules.
InRule is proprietary, whereas nxBRE supports RuleML (the defacto standard).
You might need to make your own implementation for the pages, and use the rule engine as the "structure".
At this moment, I know that Sharepoint 2007 supports page workflows (using WF), but this would imply using .NET Framework 3 and deployng sharepoint.
My suggestion would be to use whatever you find more light and easier to use.
I think the term "workflow" is very open to interpretation. I have been working lately with a type of workflow that is very different from what you seem to be describing. Mine is a state machine based workflow where the state of a particular record determines what actions a user can take to move the record to the next step in the business process. So "workflow" in this instance means how the record flows from one state to another until it is finally completed.
Your usage of workflow seems to have more to do with moving a user from one page to another in a linear multi-step process, which is a completely different use case (correct me if I'm wrong). So before coming up with a general purpose "workflow" engine that anyone could use, I would recommend defining a little bit better exactly what types of situations this system would handle.
I've been using this for a few months http://objectflow.codeplex.com. Not asp specific but it may fit your needs
While browsing the web for some workflow & BPM resources, I found the following project: NetBPM. Unfortunately, the project seems to be stopped.
I don't think there is a workflow engine that will automatically handle state for you, but if you are moving through a set of pages like a process such as checkout on an ecommerce site, perhaps the ASP.NET wizard control could help you?
There are few workflow options. "Aspose" and "Skelta" are the offers I´m evaluating.
Fábio
you can use WorkFlow Engine, just read the document and run the Demo.
all of the features you need for a dynamic workflow engine they added in there.