I'm planning to develop a timesheet system that requires users to fill out a form, submit, and requires manager approve/reject, and finally submit to finance. Since there's quite a bit of workflow, is WF a good tool for this kind of thing? I'm going to code it in ASP.NET.
Workflow would be a good fit for all process related code you need to write. So stuff like the submission, approval or rejection and handling the fact the it is dormant for an excessive amount of time.
A few things to keep in mind.
If you are going to use ASP.NET I presume the workflow will be hosted there. So you need to make sure the workflows can run after IIS recycles the AppDomain.
Think about whether to use WF4 or WF3. WF4 is a complete new animal and only in beta. WF3 was release as part of the .NET 3.0 release but has a limited future. It is sill there in .NET 4 and will still be supported bu the bulk of the work will be on WF4.
Related
I am considering using a web application in place of a traditional UI to control an imaging system. The UI will allow the user to do things like change settings, upload scripts, start/stop data acquisition, view data, etc... Rather than a monolithic UI that "does everything", an embedded controller would interact with system hardware and control the process, receiving commands from the UI over a local network.
I would probably use a javascript toolkit or perhaps some .Net technology to build the web application. A few of the advantages I see are:
Access UI from any browser.
No software to install.
Access remotely if necessary.
View status/data from multiple computers simultaneously.
Modular (separation of concerns)
Data as a web service.
A few of my concerns would be:
Lack of a comprehensive widget toolkit.
Supporting multiple browsers, this may not be as bad as I think now with HTML5.
Updating the UI from the server.
My questions are, Is this common? Is it a bad idea?
If it's really subjective, I understand, however, I just wanted to see if there is an obvious answer, like "DON'T DO IT!!!!"
It is very common. I do it all the time, particularly for a closed community of users such as you will have.
It might be different if this was a public facing device, but it is not.
You are going to support more devices by saying "you must have an HTML 5 browser" than if you said "You must have a PC" or "You must have a Mac"
In terms of your concerns, I do not see any of them as being an issue.
It is easier to deploy a UI upgrade once to the imaging controller than many times to all of the client machines.
There are all of the widgets that you could ever want available for HTML 5 compatible browsers
You answered your own question about cross browser issues. HTML 5 browsers are free so there is no downside for people to upgrade to them and you have the entire weight of the world wide web pushing them to upgrade to take advantage of what can be done with HTML 5 so users have a big incentive to upgrade. I do not run into any push back when I require a closed group to use an HTML 5 compatible browser. And if you want to be kind to those that don't have html 5, you can always use modernizr.
It is a good idea - and there is plenty of examples and ways of doing what you want to do.
I'm trying to find a CMS that can be incorporated into an existing MVC3 app.
I've played with N2, and can't get the damn thing to work in VS2010 or with .NET 4.
Umbarco doesn't appear to support MVC yet
Orchard looks great, but wants to own the whole application.
DNN is just a mess.
Any other brilliant solutions?
Post-mortem Dec 2011
This is an old post, but I thought I'd share my experiences with Orchard, and why I decided to go a different direction.
NHibernate
Aside from the very large number of transactions per page (literally dozens in some cases), each and every query was executed using sp_executesql. While not quite as bad as using Exec(), this rubs me the wrong way. Currently, my database is locked down so that applications can only execute stored procedures - that is, they can't perform select/update/delete, list entities such as tables, get any metadata, etc. This is a requirement for tier-wise unit testing, compile-time verification of the database, security and encapsulation of database logic from the application code.
Source Deployment
Orchard requires that the entire source for your site (views, .cs source files, etc) is deployed to the production server. The sheer number of source files that need to deployed boggles the mind.
Integration with an existing application
The manner in which Orchard is structured effectively requires it to be the point of entry for the web application. This means that you're going to spend some time modifying and reimplementing your app to get it to play nice with Orchard.
Conclusion
There were quite a few other issues that I encountered, but those are the highlights. Individually, each of those could have been a deal breaker. Together, they removed Orchard as a viable solution.
I'm now evaluating Telerik's Sitefinity. It's not MVC, which saddens me, but:
The admin interface is extremely powerful. Aside from a master page and some stylesheets that I put together in VS, we've been able to handle all of the layout via Sitefinity's admin tools.
I mean, it's really powerful. You can use the admin interface to edit the admin interface. Think about that for a minute.
Widgets are implemented as ASP.NET user controls. Most of my existing controls just dropped right in with zero modifications.
Database access is handled via Telerik's OpenAccess ORM. While Sitefinity doesn't natively use stored procedures, OpenAccess fully supports using them for all operations. Also, according to Telerik, OpenAccess does not, in any way, rely on reflection, which provides significant performance benefits in heavy-load apps.
There are several solutions available for using Razor markup within widgets, which is one of the great benefits (to me) of using MVC. Also, I've been told that native Razor support is in active development.
It's not free. In reality, however, a few grand barely breaks the noise floor in terms of development time.
Super crazy fast. Startup time is a bit on the slow side, but once it's running, it's very quick.
Built on top of Telerik's awesome, proven RAD controls.
Apologies for the long post. Hopefully this will be helpful.
You might find these projects useful. You can probably model a simple CMS based on one of their projects.
MvcCms
MvcMS
Atomic CMS
Mytrip.mvc
Try Web Noodles..The new CMS developed using mvc3. WebNoodles.It is easy to integrate .But the thing is it is still in beta stage..But you must give it a try ...
I'm a junior VB.net developer with little application design knowledge. I've been reading a lot of material online regarding different design patterns, frameworks, and methodologies. It's become a bit confusing for me.
Right now I'm trying to decide on what language would be best suited to convert an existing VB6 application (with SQL server backend.) I need to update the UI and add more user functionality and reporting capabilities. Initially I was thinking of using WPF and attempting the MVVM model for this big project. Reports would be generated from SSRS.
A peer suggested using ASP.net and I don't have enough experience to determine what would be better. The senior programmers here are stuck on using VB6 and don't have any input on what to use. They are encouraging me to use the latest technologies.
This application would be for ~20 users in a central location. Ideally I would stick to a Microsoft .net language. Current interface is similar to a datagrid table where the user would click in to see the detail of each record. They would need to have multiple records open at any given time.
I look forward to all the advice I can get.
EDIT 2010/04/22 2:47 PM EST
What is your audience? Internal clients within an intranet
How complex are the interactions you expect to implement? not very... displaying data from SQL server to UI. Allow user updates to said data. Typically just one user modifying a record.
Do you require near real-time data updates? no
How often do you expect to update the application after the first release? twice/year
Do you expect a well-defined set of client platforms? Yes, windows xp environment, potentially upgrading to Win7. Currently in IE.6 moving to IE7 or 8 within a couple of months.
Do users need access from anywhere? No, just from their PC.
What would be wrong about building a simple ASP.Net application in VB.Net using Gridviews for allowing the data access and manipulation? Seems like a simple ADO.Net trial application if you aren't familiar with it in the beginning you will be by the end. CRUD applications are pretty common so it shouldn't be too hard to build it and then refine it as more requirements become apparent.
Sounds like you need to use a web-based solution--this eliminates alot of your potential distribution woes with multiple users. You could use silverlight, but if you are locked into SSRS, this might not be the way to go.
We are in the process of implementing the sharepoint application, we would like to know the the pros and cons of SharePoint workflow versus Windows workflow.
Workflows in SharePoint are implemented using the Windows Workflow Foundation, so they are not that different, but there still are some things to be aware of regarding that implementation.
SharePoint is a Windows Workflow host, so you don't have to implement your own host which is fine if you agree with the decisions made by the SharePoint team:
Workflow instances are persisted in the content database
Communication with the user is through SharePoint tasks
Every workflow instance is tied to a list/library item
Tracking is not implemented
If these choices are to your liking then by all means use the SharePoint workflows.
If not then implement your own host and make your own decisions.
They are the same thing. The current Windows Workflow Engine was created for SharePoint.
Now it should be noted, that the Workflow engine is going to be overhauled with the release of .Net 4.0. I don't know the specifics, but I've been told the differences are significant. I woudld assume this is going to be used in Sharepoint 2010, but I don't have any information on that.
Here is a link describing the upgrade in 4.0.
You haven’t specified whether you’re building a custom coded application in SharePoint or configuring an out of the box solution via the browser. Either way, here are a few options for workflows in SharePoint.
Use the native workflows built into SharePoint and readily accessible from any list. They’re very basic (mostly simple approvals with one or two steps), but they’ll get you up and running very quickly and it can all be done via the browser.
Use SharePoint Designer to build slightly more complex workflows. This will give you access to conditional logic (i.e. route a workflow based on a list value) and unlimited steps and well as a number of other features that allow you to introduce more logic into the process. The downside is you have to work with SharePoint Designer which, to be frank, can be a real pain.
Custom code your workflows in WF. Windows Workflow underlies the first two options which are essentially abstractions on top of the underlying framework. The main difference with this approach is that you’re not limited to the functions that the browser or SPD surface. The downside is that this becomes a more complex process (although admittedly the workflows will likely be more complex) and you have to go through the rigmarole of coding against SharePoint, packaging deployments, publishing, etc.
I find the best balance in terms of ease of development and functionality is to try and work through the above list in the order I provided them and only progress to the next option if you definitely can’t implement the requirement with the current point.
It's basically the same technology. If you know one you can easily work with / switch to the other.
When you add the SharePoint dll to your solution you get some specific SharePoint 'activities' that you can use in your workflow. (create task, ...)
Your SharePoint Server will act as a host for your workflows.
The best way to deploy a workflow in SharePoint is by using a SharePoint feature. This tells SharePoint what dll (assemblies) to use and which (input) pages to show.
As input pages you can use simple .net aspx pages or infopath forms. Both require some trial and error to get the hang of it.
SharePoint simply uses windows workflow Foundation (WF) as its workflow engine. WF in itself is just a generic workflow engine.
In order to use WF you must implement a host process for the execution of workflows, and configure it so it persists instances to database etc (these days most people use a WCF service as a workflow host, see here or here).
SharePoint comes with everything already configured and implements its own workflow host, so you can start using workflows out of the box. Apart from that, it comes with custom activities and other goodies specific to SharePoint.
As stated in other answers, they are the same, as they use the Windows WOrkflow Foundation. That being said, there is a major thing to keep in mind when it comes to Workflows created through SharePOint Designer: They are not "portable" out of the box, meaning that you can create one bound to list a, then save the list as a template and then create another list based on that template, the workflow will NOT work (you have rebind it as it is still referencing the original list's id (guid).
Present:
The product development is done in Visual Studio at the moment using .Net technologies, so it's important to stay in the same set of tools. Roles apart from developers are using spreadsheets, docs and diagramming tools, photoshop to do their work.
Future:
We want to build a workflow (a sequential process with roles, queues for action items, passing on info from one role to the other, approval etc) for a product development. The software product will be in enhancement stage forever, more the reason to establish this flow.
Typical users are designers, business analysts, content creators, developers, code reviewers, testers.
Let's say a new webpage needs to be developed. It will be,
thought about by the analyst in the
tool, will enter the information in
some format
a designer will use drag and drop to
build the page look, pass it over to
the
content creator, who will add
content(help text, hyperlinks, pure
text etc) to the page
a developer will check his queue to start
building logic around this page and
make it functional.
I am thinking about Visual Studio Isolated shell to be used as a tool framework mainly due to it's IDE capabilities et al, to build this. Has anyone worked on a similar set of requirements? Any patterns/solutions/ideas around how to go about this in the VS Shell paradigm?
Update: Visual Studio Team System is already being used by the developers and testers, but there is no customized workflow for them (& analysts, designers etc) available in TFS. Also Visual Studio is not the place for non-dev users that want to do things like, - define navigation flow, design the page elements etc.
Sounds exactly like Microsoft Visual Studio Team System.
I think there is a market for this product as I could not find anything close. There are disparate tools and products but no unified IDE like experience available and needs to be built on our own.
VS Isolated Shell 2010 is the starting point and platform on which this can be built. Needs several man months and may be years. However TFS ALM application lifecycle management has several overlaps of features with this idea, although not all, because it doesn't provide a customized experience per your custom workflow.
Jury is out, needs figuring out.