Is WF used at user interface or business layer? If at UI layer, then does someone coding in business layer even need to use or learn it?
Chris offered a great answer, so I'll take a different tack. Workflow is really not the same as logic. Workflows are generally compositions of logic, which makes them a complimentary contributor to the whole. Where a business component nicely encapsulates a single piece of business rules or behavior, a workflow composes multiple business components, rules, and behavior to meet the needs of larger, longer-running business processes.
Workflows can fit anywhere, filling process needs for UI, business, and even data layers. If you do end up using WF, I highly recommend that you train your general development staff, so that there is broad knowledge and understanding. Despite having a visual aspect to it, WF still requires some low-level coding to build up a library of activities and such that workflow creators and maintainers will use.
EDIT:
Its up to you whether to use it or not. Generally, WF is used by larger projects, because WF offers a valuable return on investment. WF is harder to use than simply writing code. There is a fairly steep learning curve, requires a different way of approaching business problems, and requires special skill sets. Providing code to WF adds overhead, as you have to write activities that may be used in workflows, as well as build the workflows themselves.
If you think that using WF for your small project will provide a valuable return on investment, then go for it. You will need to both recoup the initial costs of training, infrastructural implementation, and deployment, as well as providing long-term, tangible cost savings over simply writing code to solve the problems at hand. I would be doubtful that WF will offer a small project such ROI. For larger projects, or multiple integrated projects for a single large company, it is much easier to realize that ROI than it is with smaller projects, which is why workflow platforms like WF are usually only used on that scale.
WF is the interface to the buisness layer.
Workflows are a declarative way of writing programs by linking together pre-defined activities rather than an imperative programming model of writing lines of code. IN addition, you have many graphical tool that allow you to wrtie workflows. shuch as black pearl, K2 and sharepoint designer.
They are very much used and are well worth learning. I started using then in sharepoint and ms crm. I now always look to workflows to solve my common problems.
here are a few links:
mirosoft msdn.microsoft.com/en-us/netframework/default.aspx
Wkik: http://en.wikipedia.org/wiki/Windows_Workflow_Foundation
WF is mostly understood quite imperatively - a sequence of chronological events.
However, if you delve deeper you can combine activities in different ways. A good example are the state-based workflows that are usually also shown when presenting WF. WF allows you to put the Workflow into an idle mode: It's current state is persisted and reloaded once e.g. an external event takes place. As such, workflows can be useful in tracking long-running interactions where the system has to wait e.g. for some external process to end or some user to interact with the system.
I'd say that WF wouldn't be terribly useful in the UI context. They are better suited as a backend module to express processes integrating several services that have a tendency towards changing in time.
From my point of view, though, it is noticable that WF is a version 1 product: There are a number of awkward things that may guide you into code that is hard to maintain, parts of the infrastructure are quite complex to be used, you may find some API inconsistencies here & there.
There is also a guideline out there what you shouldn't do if you ever want to port your workflows to the next generation of WF.
Related
I'm a fresh graduate and having trouble which is the best way to create a web project if branching or single web project with many conditions.
FOR EXAMPLE: I have multiple clients with different insight about our system. Some clients want to use certain features while others wont.
SOLUTION 1: Create each branch for each client to separate their project buildup
PROB. ENCOUNTERED: If I have multiple clients who wants the same features it would be very tedious to repeat the programs.
SOLUTION 2: Only have a single project that have many setup conditions to activate feature depending on the clients need
PROB. ENCOUNTERED: This will be slower because each feature that can be unique for each client should have a program condition. It is also much harder to debug in this solution.
Probably the easiest way is to use a plugin style system. If you define it correctly it will make for updating the system easy if there was a bug in one of the features that a client desires. Now you can still ship the program with all the features, but in a config file you could turn features on and off. Now this will require you having a good logging system in place. Both of these systems require a fair amount of research.
Any sort of branching as you suggest is a bad idea. I would recommend that you use Git instead of TFVC in TFS and use Git flow (http://nkdalm.net/Git-Flow) for your branching strategy.
As long as your branches are short lived (hours not days) they can be useful. If you end up with a branch for each customer you will end up with too much technical cruft and ultimately drowning in complexity. This is not a pleasant place to be.
You should invest in, and implement, a good feature toggle system that you can use to enable and disable features for customers. Where you hit an identical algorithm or behaviour that needs to be different per customer you should implement a switch possibly with dependency injection or plugins.
If you use good engineering practices, practice some form of test first, and maintain working code at all times, you should never need more than a single long term branch.
Currently I am preparing exercises about networks and mobile communications for students. I was thinking about creating an interactive user-interface which enables the user to drag&drop predefined elements and then implement a logic based upon element distances etc.
An example would be to place two base stations (a predefined element with several properties), set the scale in the interface and then check the signal interferrence in the environment (user-interface).
The first part might be too abstract whereas the example might be too specific, but I was wondering whether there already exists any friendly framework or language which enables developers to create interactive interfaces (for teaching/learning purpouses) in short ammount of time. Usually I write applications for PC environment in .NET but in this case it would take too much time to create a specific interface for every exercise.
I would appreciate if anyone could suggest any way to create interactive user-interface in short ammount of time. Are there any special programming languages or development tools for this kind of applications or are there any useful frameworks for .NET, Java or any other language to speed up the development of user-interfaces?
Thank you!
Perhaps sketchflow could be of interest
although more intended as a tool for mocking up GUI's. It does also have the ability to hook up behaviours and other short snippets of code to your testgui.
Take a look at Mockingbird. I'm not sure if it's exactly what you are looking for, but it is a pretty sweet web application and works well for the development of UIs (at least the wireframes).
There are lots of tools for this purpose -- but most of them only work well if your user interface follows one of a few fairly well-defined (and widely used) patterns. Just for example, if you're creating a database front-end, there are quite a few tools to make the job quite easy.
One often-overlooked tool for this kind of job is Visio. Visio is normally thought of primarily for drawing and diagramming, but you can also attach behaviors to objects so double-clicking an object can run a macro of your choice, opening forms, doing calculations, etc. The macros are (at least normally) written in VBA, which probably isn't the greatest choice for big projects, but as you said, for a situation like this you're mostly interested in short snippets.
There are, of course, a number of downsides to this, such as the inability (at least AFAIK) to deploy such a diagram as a web-based application. Like Henry Ford's "they can have any color they want as long as it's black", you can respond to any user action you want as long as it's a double-click.
Microsoft expression blend might bee something cool too
http://www.microsoft.com/france/expression/default.aspx
Many poeple have online startups in their head that may potentially attracts millions, but most of the time you will only have minimal budget (time and resource) to start with so you want to have it delivered within a year's time. Short after launch, you are bound to perform one or a series of upgrades that may include: code refactor to newer foundation, adding hierarchy(ies) in software architecture or restructure database(s). This cycle of upgrade/refactor continues as:
New features avaiable in latest version of the language(s)/framework(s) you use.
Availability of new components/frameworks/plugins that may potentially improve the product.
Requirement has changes it's direction, existing product wasn't designed to cope with new needs.
With above as prerequisite, I want to take this discussion serious and identify the essence of an upgradable solution for a web application. In the discussion you may talk about any stages of development (initial, early upgrade, incremental upgardes) and cover one of more of the following:
Choice of language(s) for a web application.
Decision for using a framework or not? (Consider the overhead)
Choice of DBMS and its design
Choice of hardware(s) and setups?
Strategy to constant changes in requirements (, which can be a natural of web application)
Strategy/decision toward total redesign
Our company's web solution is on its fourth major generation, having evolved considerably over the past 8 years. The most recent generation introduced a broad variety of constructs to help with exactly this task as it was becoming unwieldy to update the previous generation based on new customer demands. Thus, I spent quite a bit of time in 2009 thinking about exactly this problem.
The single most valuable thing you can do is to employ an Agile approach to building software. In particular, you should maintain an environment in which a new build can be (and is) created daily. While daily builds are only one aspect of Agile, this is the practice that is most important in addressing your question. While this isn't the same thing as upgradeability, per se, it nonetheless introduces a discipline into the process that helps reduce the chance that your code base will become unwieldy (or that you'll become an Architect Astronaut).
As far as frameworks and languages go, there are two primary requirements: that the framework be long-lived and stable and that the environment support a Separation of Concerns. ASP.NET has worked well for me in this regard: it has evolved in a rational manner and without discontinuities that invalidate older code. I use a separate Business Logic Layer to manage SoC but ASP.NET does now support MVC development as well. In contrast, I came to dislike PHP after a few months working with it because it just seemed to encourage messy practices that would endanger future upgrades.
With respect to DBMS selection, any modern RDMS (SQL Server, MySQL, Oracle) would serve you well. Here is the key though: you will need to maintain DDL scripts for managing upgrades. It is just a fact of life. So, how do you make this a tractable process? The single most valuable tool from any third-party developer is my copy of SQL Compare from Red Gate. This process used to be a complete nightmare and a significant drag on my ability to evolve my code until I found this tool. So, the generic recommendation is to use a database for which a tool exists to compare database structures. SQL Server is just very fortunate in this regard.
Hardware is almost a don't care. You can always move to new hardware as long as your development process includes with a reasonable release build process.
Strategy for constant changes in requirements. Again, see Agile. I'd encourage you not to even think of them as "requirements" any more - in the traditional sense of a large document filled with specifications. Agile changes that in important ways. I don't keep a requirements document either except when working on contract for an external, paying customer so that I can be assured of appropriate billing and prevent feature creep. At this point, our internal process is so rapid and fluid that the reports from our feature request/bug management software (FogBugz if you want to know) serves as our documentation when documenting a new release for marketing.
The strategy/decision for total redesign is: don't. If you put a reasonable degree of thought into the process you'll be using, choose mainstream tools, and enforce a Separation of Concerns then nothing short of a complete abandonment of HTTP and RDBMSs should cause a total redesign.
If you are Agile enough that anything can change, you are unlikely to ever be in a position where everything must change.
To get the ball rolling, I'd have thought a language/framework that supports the concept of dependency injection (or Inversion of Control as is seems to be called these days) would be high on the list.
You will find out that RDBMS technology is not easily scalable. All vendors will tell you otherwise yet when you try multiple servers and load-balancing the inherent limitations will show up. Everything else can be beefed up with "bigger iron" and may be more efficient code but Databases cannot be split and distributed easily.
Web applications will hopefully drive the innovation in database technologies and help us break out of the archaic Relational Model mind-set. It is long overdue.
I recommend paying a lot of attention to this weak link right from the start.
I work in a small and young team of developers and we have problems that we are not sure how to solve.
On previous projects every developer have been working on tasks that were based on use cases. So, upon setting the system architecture, each team member worked on user interface and business logic of tasks assigned to him.
This kind of organization gave us the problems with UI. Each developer had his own logic about how UI should look like, where buttons should be, etc etc... and even if we've had one css designer a lot of refactoring had to be done in order to make web site to look compactly.
How do you deal with this issue?
Do you split tasks based on layer, not on whole use case?
Do you use some technical solution to achieve this or is it just written standard that every developer need to follow?
Thanks
Everyone has their own style and it would be difficult and a waste of time to define a standard that would get everyone to draw the UI in a consistent manner. Instead, elect your best UI designer to do what he does best and design the UI for the whole system. Funneling all UI changes through the designer would be difficult so just let your developers "mess it up" as they implement new use cases and just have your designer clean it up before the release. It shouldn't be hard for him/her to rearrange the existing forms and bring some consistency back to the UI.
I've found this 12 Standard Screen Patterns article very useful.
A solution might be to create sketches of all screens of your application, have them reviewed by an ergonomy-expert to correct the biggest mistakes, and, only then, give them to your developpers.
This way, they would know how the screens they are developping should look like -- there will still be a couple of differences in the end, but those should not be "big differences", and should be eaiser to fix.
And this would mean not each developper has to imagine what the perfect screen would look like : each one of those would be coherent with the others.
Adopt the tried and tested MVC system, let the view be decoupled from the business logic. Then ask a UI designer to produce sketches and work to that. UI's are something best done top-down from my experience. The user gets an overall view before being presented with all the details, defining and capturing this hierarchy makes good UI's. Coding of business logic is done as you mentioned on a use-case basis, mostly bottom-up and this is where the code falls out of sync with the UI.
Designate one person (preferably someone with graphic design experience, even if they're not really a programmer) and give them the authority to make cosmetic changes to all forms, pages and controls at any time, and have them be responsible for the overall look and feel of the application.
As far as metrics go, keep track of how much time this one person has to spend "fixing" each programmer's work, and make sure the programmers are aware of these numbers. The idea is to encourage them to make their stuff look like it should from the beginning, but also not to do weird things based on what they think stuff should look like. I've had to spend more time undoing my coworkers' bizarre design choices than anything else.
Don't be afraid to have outside sources review the design work of each programmer. It's very common for programmers to 1) produce horrible-looking UIs, and 2) believe the UIs look fantastic. You should do what the Army does with boot camp: break them down completely right from the start, so that you can build them back up again the right way.
Part of the problem with creating your own written standard is that while well meaning, there could be mistakes or better ways to do things than what's been standardized. For example, where I work, the standardized cancel button does nothing when you click on it (it's been wired to Reset).
Instead, I recommend choosing existing standards, such as The Macintosh Human Interface Guidelines or Windows User Experience Interaction Guidelines. Even if the standard is wrong, it's rarely profitable to deviate from widely established conventions.
Then pick up some good books for the developers, such as "Designing Interfaces: Patterns for Effective Interaction Design". Good user interface design is partially a matter of good taste, and while not every developer will be interested in the subject, it's in your best interest to help them improve.
Next, empower your QA team to file bugs when the interface for one product is inconsistent with another. The developer can then either standardize or justify the deviation if he has a reason. We do this; it works pretty well.
Lastly, go over your existing products and get a consensus on how their interfaces should be unified. Bring in (and keep) a usability expert if you can. I've seen good ones do amazing work.
There really is no clear solution for how to deal with UI problems. There are however several approaches one can take to combat the problem of having things become too complicated:
Use cases are usually cross disciplinary in nature, thus the responsibility to get a use case done should be split between the people who can implement it properly. Programmer and designer type of people need to cooperate.
Everyone in the team needs to keep in mind seperation of concerns, i.e. things that can be seperated must be kept that way preferably as early as possible. There are so many ways to do this: e.g. apply MVC pattern in your project (which is a very wide way to put it). Presentation and logic should be seperate so that changes in one layer should not affect the other.
Someone needs to be responsible for the overall UI design so it is consistent throughout the application. Preferably someone who is both a graphic designer and has some insight in usability. UI design is something that needs to be planned along with the use cases and revised constantly as development goes on. Consistent UI is very important and developers need to be on board on it.
Hi I would like to know how many of you have used Workflow in your production environment and Was it good idea? I mean we can create the same thing using DB and scheduler service
We use WF in our production enviorments. We have 6 different workflows that can be run. These split into 3 statemachine and 3 sequences. I would use it again in some circumstances, but I would not in others. I would claim that the statemachine part of the workflow was tacked on the end quickly, I'm not sure it a core part of the workflow all the way through design.
I would use workflow again for short running processes like quotes or transforming things before sending them to supliers that kind of thing.
I would not want to do it again for a long running statemachine - mainly because there is not a built in WF upgrade process so we ended up writing our own. There are also a lot of concepts to get your head around (affectionalty known as gypsy curses with in our development team).
I would also be slightly concerned about performance: our App server is currently running flat out (ok I am restarting 8000 workflows at the moment). This is especially a problem if you integrate it directly into WCF using the (.NET 3.5) send and recieve activities - there are some properly crazy config settings you have to set to allow it run multiple workflows at once.
Anyway, as I said: it is useful, I would use it again, but not for another statemachine.
Also see Please confirm: Is Windows Workflow Foundation a good horse to be backing right now?
We use Sharepoint, which uses WF for its workflows. It works pretty well and is fairly easy to customize. If you need an advanced workflow, WF can support it but it will take some training to learn the ins and outs.
You could roll your own workflow, but why reinvent the wheel? WF is built into the .NET 3.0+ framework and is pretty robust, so you might as well take advantage of it.
Most people say all the good things about Workflows but I have observed that they introduce unnecessary code complexity and maintenance problems. They are suitable for a particular class of problems. other then that they need a lot of code plumbing and maintenance nightmares.