We have an ASP.NET MVC application that's used for document circulation. Pretty straight-forward! The system is something like this: you write and publish a document and it gets through a number of people for the approval, at the same time may gets rejected. Except write / publish, rest of the processes are almost same. Just approve or reject.

Now we would like to make it dynamic and create different processes in the database to handle them in the frontend. As an example, suppose we have two new processes - Recruitment and Loan.

For the entry or publish, we can have two different forms. But for approval and rejection, these things should be handled dynamically in one form or in a UI. Say for approval, there are five people involved. So with their approval, the document is ready to get printed or whatever the requirement is.

Currently we are in the initial stage and in database, we have something as follows:

Table - ProcessDetails:

WorkFlowID - ApproverId - StepName - StepOrder - ActionType

WorkFlowID is the id of the process that we create. Suppose, in this case it's a recruitment process. We create an initial document and it should be approved by 5 different people that are involved. These approver details are saved in the above table. This is what we did so far.

Now the main challenge is in the frontend. To approve the document, we want to provide a single screen for all processes. It could be recruitment or loan process whatever. I am not sure of this, but my idea is something like this: a generic type should be there and it should be able to handle all processes as follows for the approval part:

// Define a generics class named Document
public class Document<T>
{
    // Define a variable of type T 
    public T data;

    // Define a constructor of the Document class 
    public Document(T data)
    {
        this.data = data;
    }
}

So whatever the process is, that should be able to be rendered in the frontend with the generic type. So for now, we create classes for all of the documents and create different forms each time there's a new process as follows:

public class RecruitmentDoc : Document
{
}

public class LoanDoc : Document
{
}

Is this the correct way to handle this kind of scenario? Any POC would be much appreciated in this regard.

NB: in the frontend, we use Razor. So any example or source with Razor would be really of great help.

We have an ASP.NET MVC application that's used for document circulation. Pretty straight-forward! The system is something like this: you write and publish a document and it gets through a number of people for the approval, at the same time may gets rejected. Except write / publish, rest of the processes are almost same. Just approve or reject.

Now we would like to make it dynamic and create different processes in the database to handle them in the frontend. As an example, suppose we have two new processes - Recruitment and Loan.

For the entry or publish, we can have two different forms. But for approval and rejection, these things should be handled dynamically in one form or in a UI. Say for approval, there are five people involved. So with their approval, the document is ready to get printed or whatever the requirement is.

Currently we are in the initial stage and in database, we have something as follows:

Table - ProcessDetails:

WorkFlowID - ApproverId - StepName - StepOrder - ActionType

WorkFlowID is the id of the process that we create. Suppose, in this case it's a recruitment process. We create an initial document and it should be approved by 5 different people that are involved. These approver details are saved in the above table. This is what we did so far.

Now the main challenge is in the frontend. To approve the document, we want to provide a single screen for all processes. It could be recruitment or loan process whatever. I am not sure of this, but my idea is something like this: a generic type should be there and it should be able to handle all processes as follows for the approval part:

// Define a generics class named Document
public class Document<T>
{
    // Define a variable of type T 
    public T data;

    // Define a constructor of the Document class 
    public Document(T data)
    {
        this.data = data;
    }
}

So whatever the process is, that should be able to be rendered in the frontend with the generic type. So for now, we create classes for all of the documents and create different forms each time there's a new process as follows:

public class RecruitmentDoc : Document
{
}

public class LoanDoc : Document
{
}

Is this the correct way to handle this kind of scenario? Any POC would be much appreciated in this regard.

NB: in the frontend, we use Razor. So any example or source with Razor would be really of great help.

• c#
• asp
• asp-mvc
• -4.8

• I try to filter out your requirements and I might conclude false, but an option might be to create a factory that generates a non-generic document type with all the requirements attached. If something needs to be generated, then you could have a generic render method in that document type. However, your question seems elaborate, but in my opinion it is too abstract, some pseudo code with all your requirements would help. – Silvermind Commented Mar 13 at 17:11
• Are you handling "loans" or "loan applications" or just "documents"? along the same lines, are these "job applications"? Job "postings"? A document retrieval system is not the same as an information system. – Gerry Schmitz Commented Mar 13 at 21:49

1 Answer 1

I'll briefly discuss the Document<T> idea below, but first, some general observations.

Whenever you're considering a general-purpose system, your first question should be: Does such a system already exist? Is it the best use of our time and resources that we work on implementing a poor version of something we could buy as an off-the-shelf solution?

Document workflow systems isn't my normal stomping grounds, but I'd be surprised if you can't find systems that already exist. SharePoint comes to mind, but surely something simpler and better suited also exists.

Even if a standard system doesn't exactly fit your requirements, consider that most commercial offerings have years of head-start compared to you.

A generic system not only requires a flexible engine. You'll also quickly meet the requirement that super users want a general-purpose admin interface so that they can define the details of their special workflows. Now you also have to develop an admin system, and then a user system with hierarchies of super users, admins, etc.

In short, beware of the inner-platform effect.

As promised, however, I'll also briefly touch on the notion of a Document<T> type.

As presented, it's isomorphic to the Identity functor. This kind of data structure is marginally useful in languages with higher-kinded types (Haskell, mostly), but of little use in languages that don't have the capability to abstract over container types. No .NET language can do that.

So unless you plan on giving Document<T> some domain-specific behaviour that works for any T, I see little reason for that design.