Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
We have an ASP.NET web-application which has become difficult to maintain, and I'm looking for ideas on how to redesign it. It's an employee administration system which can be highly customized for each of our customers. Let me explain how it works now:
On the default page we have a menu where a user can select a task, such as Create Employee or View Timesheet. I'll use Create Employee as an example.
When a user selects Create Employee from the menu, an ASPX page is loaded which contains a dynamically loaded usercontrol for the selected menuitem, e.g. for Create Employee this would be AddEmployee.ascx
If the user clicks Save on the control, it navigates to the default page.
Some menuitems involve multiple steps, so if the user clicks Next on a multi-step flow then it will navigate to the next page in the flow, and so on until it reaches the final step, where clicking Save navigates to the default page.
Some customers may require an extra step in the Create Employee flow (e.g. SecurityClearance.ascx) but others may not.
Different customers may use the same ASCX usercontrol, so in the AddEmployee.OnInit we can customize the fields for that customer, i.e. making certain fields hidden or readonly or mandatory.
The following things are customizable per customer:
Menu items
Steps in each flow (ascx control names)
Hidden fields in each ascx
Mandatory fields in each ascx
Rules relating to each ascx, which allows certain logic to be used in the code for that customer
The customizations are held in a huge XML file per customer, which could be 7500 lines long.
Is there any framework or rules-engine that we could use to customize our application in this way? How do other applications manage customizations per customer?
If your regular data is held in a database I'm not entirely sure why you'd want to have all of that customer specific information in an xml file. Move it into the database.
Next, there are many different kinds of rules engines out there. Considering you're using asp.net you might want to look at Windows Workflow for at least some of this. You might read the following: http://karlreinsch.com/2010/02/05/microsoft-rule-engines/
A long time ago I used a product called Haley Rules to drive a c# web app. It controlled everything from the screens that were available right down to the fields that appeared and whether they were required or not. It took awhile to get the team on board with how it worked, but once that happened bringing on a new client was extremely simple. Haley was since gobbled up by Oracle, but was probably the absolute best one out there.
Others you might be interested in are NxBRE and even nCalc. NxBRE is an actual rules engine which is a port of one built for java. nCalc on the other hand isn't a rules engine per se. However, if you can express your logic in simple boolean statements then it is extremely fast. I'm currently using this to drive page flow in one of our applications.
Some commercial ones include: FlexRule, iLog
Your existing rule engine tool supports your web application, which means it meets your needs already. You can use other "Rule Engine" like MS work flow, but IMO it can also end with a hard to maitain situation.
Let's say there is registration portal. It collects general user infomation and save them into database. Simple. we build one protal for one client with several ASCXs and Rules.Then for another client,we add more rules and more controls to these ASCXs. Working in this way, sooner or later we will reach the final straw client. At that time the code base is hard to maitain and devs lost themselves in lots of rules. It is what happened to me.
So to me, it is not about which Rule engine to use.
Then How?
I have raised a question, and one of the answer makes sense to me( thought not a picked answer). In this answer, the guy mentioned what kind of company you are. In your question it is more like which department you are or do you want to seperate your dev teams.
If you are in a archetect teams, build a framework with a rule engine. Create a basic registraion portal as a sample portal.Make DAO,BO decoupled with UI (Seperate layers).
If you are in a customise teams, create customised user control (dont reuse these user control in basic version). What you will recreate is just UI, you can still use DAO,BO as they are not defined in user control, they are at other layers. In this way you get the freedom to define your client specified rules without worring about contaminating other clients rules or introducing new bugs to other client's registrations.
Just realise it is not like an answer to your question. Anyway it is my thoughts after limited xp of working on a engine rule based ,multi-clients web application.
Related
Lets say you are developing an web app that requires that you are able to Add/Edit items. The item form contains several input control. Would you separate the add/edit pages or use the page for add/edit and control via querystring (i.e. ItemAddEdit.aspx?isEdit=1)
The advantage I see in separating is that it is easier for the (non-technical) user to type the page and to determine whether it is add or edit. Also, when there would be specific changes to each page (if ever), it would be easier to change.
For the single page, well, you reuse code which eliminates some duplicate code and avoid possible problems.
And no, I can't use routing.
This is generally something which could be a subjective thing, because there's as many ways of doing things as there are coders, and a lot of it can be depending on how your system is set up generally.
But, if I were to recommend, I'd say the way you should do it if working with asp.net web-forms is to make two web pages (add/ edit) and then you use a user-control on those to group up the shared logic between the two pages. After all - that's why we have user controls.
In this way you can have both of your situations, by keeping logic in one file/class, but still have two entry points.
This would also mirror more how MVC does it, which could be considered a plus.
That being said - if your administration functionality is behind login etc, there's nothing to hinder for actually doing it in one and separate with the query string approach, and then just load the data if editing or display "empty"/base data when creating.
You shouldn't have the user type the addresses anyway, but click through the links to follow your flow, so the query string should be a minimal issue.
But for the sake of keeping your functionality clean and divided, I'd personally recommend going for two page / usercontrol approach.
Our team is building a new web site with ASP.NET. We plan to use a 3-tier architecture. The problem is that the controls shown on the web page need to be changed all the time according to the customer's requirements, which means adding a pair of label/textbox, or removing a pair of label/dropdownlist when the customer needs it. So the layout needs to be flexible and allow to easily add or remove controls, although it just shows some simple product messages like price, discount, tax, etc.
The previous version of the web site saved all the control information in a database, like control name, control type (textbox, label, dropdownlist), which page and panel it belongs to, etc. You can see there is a big performance hit because every time there is a request to this page, it needs to get all the required controls from the database and add them to the page manually, no matter whether the request is a postback or not.
We thought about adding the controls directly to the .aspx page, but in this case it will be difficult to change them later. We also considered holding all the controls' information in XML files, which may give a little performance advantage, but it still needs to render the controls all the time.
So this is the problem we have, to improve the app's performance and also meet the users' needs at the same time. Could anyone help me with any solutions or ideas?
PS: you can also ask questions if I didn't make it clear enough. Best regards.
This sounds like a good situation for User Controls. If all you're doing is toggling child-control visibility, then creating a user control with toggleable visibility properties should meet your needs. You can still use your backend to toggle visibility, but you'll only need to pull yes/no flags from the db instead of entire page schemas.
From an architectural standpoint, User Controls are great because they encourage modularity, code reuse, and lend themselves well to version control (UsercontrolV1.cs, UserControlsV2.cs, etc). The point on version control is especially great in cases where change requests require logic updates, or simply need to revert to a build that existed x iterations ago.
Now that is what i call a Flexible web-Application.
the controls shown on the web page need to be changed all the time
Who will change the controls? The client? Can you not just update the .aspx file and publish it to the server every time a control is requested to be changed?
but any way, its an interesting question. There is nothing else really that can be done except using a XML file.
Well, I am trying to implement a wizard interface to help the user to choose the right service then add it to the shopping cart then possible checkout or discard.
This is similar to the concept of the t-mobile / att. Where we select the type of plan then the services we want ( minutes , data plan, mobile phone device then checkout) . The UI should be very web 2.0 like there would be help text , suggestions.. etc.
The technology is asp.net 4.0 (mvp - codebehind model)
I did a lot of research, looked around using state design pattern , commander pattern.
My thinking is like a pattern where we have a Wizard controller which controls the wizard steps then once done hands over to the checkout process the end user can always go back and change any options during the wizard. Incase if its a existing customer then we have to skip few steps as we already few details.
Its all custom UI, I was thinking to use asp.net mutliview and each view loads based on current and next step.
In Brief I am confused and need some directions
Be aware that the multiview actually loads all details behind the scenes, one reason I don't like using it.
You could easily just have several ajax update panels. Each is the step of the wizard and when you post each item, you hide that panel and show the next step and potentially update and step indicator you have on your screen.
You have several choices -
1. jQuery and ajax calls to load details into divs
2. update panels (as described above - my choice here)
3. wizard and multiviews - Im not a fan of using them. Certain customization issues exist with these built in controls at times and you need to be wary of certain details - like multiview actually processing all data for hidden items (if they contain queries this could significantly impact your system when you don't expect them to run and they do even though the view is hidden)
Stackoverflow members,
How do you currently find the balance between javascript and code behind. I have recently come across some extremely bad (in my eyes) legacy code that lends itself to chaos (someHugeJavafile.js) which contains a lot of the logic used in many of the pages.
Let's say for example that you have a Form that you need to complete.
1. Personal Details
2. Address Information
3. Little bit more about yourself
You don't want to overload the person with all the fields at once, so you decide to split it up into steps.
Do you create separate pages for Personal Details, Address Information and a Little bit more about yourself.
Do you create controls for each and hide and show them on a postback or using some update panel?
Do you use jQuery and do some checking to ensure that the person has completed the required fields for the step and show the new "section" by using .show()?
How do you usually find the balance?
First of all, let's step back on this for a moment:
Is there a CMS behind the site that should be considered when creating this form? Many sites will use some system for managing content and this shouldn't be forgotten or ignored at first glance to my mind.
Is there a reason for having 3 separate parts to the form? I may set up a Wizard control to go through each step but this is presuming that the same outline would work and that the trade-offs in using this are OK. If not, controls would be the next logical size as I don't think a complete page is worth adopting here.
While Javscript validation is a good idea, there may be some browsers with JavaScript disabled that should be considered here. Should this be supported? Warned about the form needing Javascript to be supported?
Balance is in the eye of the beholder, and every project is different.
Consider outlining general themes for your project. For example: "We're going to do all form validation client-side." or "We're going to have a 0 refresh policy, meaning all forms will submit via AJAX." etc.
Having themes helps answers questions like the one you posted and keeps future developers looking in the right places for the right code.
When in doubt, try to see your code through the eyes of someone who has never seen it before (or as is often the case, yourself 2 to 3 years down the road), and ask yourself: "Based on the rest of the code, where would i look for this function?"
Personally, I like option number 3, but that's just because it fits best with the project I'm currently working on and I have no need to postback or create additional pages.
We have about 10 applications that basically do the same thing, all written using the Wizard Control for .Net 2.0. The flow they follow is pretty simple:
1. User selects option from a drop downs.
2. Next page has more options more narrowed.
3. User sees confirmation page.
4. Report is generated.
Some of these applications have optional pages, such as allowing the user to upload custom images for the report and allowing the user to select specific lines of data.
I'm attempting to merge these applications, but I'm not sure I'm approaching this the correct way. My first inclination is to create configuration tables in SQL to drive the menus that appear. So, for example, there might be a table with the WizardId, Name, Theme, etc., also a table of steps, and another table to link everything together.
Is there an easier way to approach this that I'm just missing?
We've been thinking through this issue lately and I've come up with two options that both seem valid, just have different uses. One way to do it, similar to what you have described, is to create the following:
A table that holds the wizard information
A table that lists the types of questions to be asked in each wizard
A table to hold the data entered by the user for each question
This is very flexible, but the problem is you have to dynamically generate all the controls you need to collect the information (textbox, drop down, radio, file upload, etc) and store how to display that control in your database.
The other approach that we have tried out on a recent project is to associate a user control with either each wizard or type of wizard step. It isn't as modular, but you have a lot of control over how the controls are arranged and how you collect the data.
I think both approaches are useful in different scenarios. Going with a database driven approach allows you to generate new questions and wizards easily, but lacks the user friendly approach that we wanted for our new application.