Design Request Tracker Application
i have given an assignment to design request tracker application using ASP DOT NET MVC 3.0.
i have identify active/functional object in the application like client,customer,request type,request status,technician,requester ,request and request history etc.
i am trying to use ,design patterns in my application.
can someone help out to identify whihc pattern will be best fit in my requirement....
Shujat Qureshi, Jul 17, 2012
$100/hr, or just buy a canned helpdesk app.
Michael Lopez, Aug 04, 2012
First of all Thanks for response. We have request tracker (for help desk team) application andthat is running successfully for 4 client but we are facing support issues likeperformance, maintainability and versioning because we have different sourcecode for each client. Current application has been designed before 5 year on DOTNET 2.0 and MS-SQL server 2005 without admin module, it only creates request,edit request and view request pages mainly. Now we are planning to redesign RT (dot net 4.0) in such away that only one application will fulfill all requirements of any client thatmeans, it should have configurable admin module. (1) One client may have more than one customer andwe will setup all require objects for this customer like request status,request type etc (see the attached image). (2) There are most important roles like requestor, technician,manager and admin. (3) Each request has to follow request stateworkflow like “NEW”,”OPEN” ,“ASSIGN”,”ON HOLD”,”RESOLVED”,”CLOSE”and “RE OPEN” We are in design phases that why I am trying to get perfect solutionof above issue. I am looking positive response from your side……
Shujat Qureshi, Jul 22, 2012
Sorry, Question needs to be more clear (?)
If you have work flow kind of scenario , you could try - Chain of Responsibility.
If you need to notify stakeholders involved, of any changes in status of a request - observer pattern.
Other than these two, more patterns get into picture, based on your requirements (if you can add detailed requriement, may be we can discuss further)
Tarriq Ferrose Khan
Tarriq Ferrose Khan, Jul 19, 2012