MVC controller-Action layout: is it a separate page for creating/editing or creating/editing/viewing an integrated page?

At the beginning, I agreed with the layout method of MVC action in Asp.net: no matter the size, as long as it is a verb, a separate page is provided, such as create/edit/detail/index.

After writing it for a while, I found it inconvenient. Especially for pages like "create role", there is only one Textbox, and nothing else. Write a create and edit statement separately, it is better to place a textbox on the top of the index page. The existing roles under the textbox are also directly used instead of text. To create a Textbox, edit it.

After writing for a while, I found this risk. This is because I have done the same for all the information on another page, but this page will have a lot of user access, and it is very easy for you to edit and update at the same time, the lock cannot be locked because I don't know who is editing anything.

What should I do?

Although I could not say that I had found a perfect solution, I finally convinced myself that this was a viable answer. That is:

For pages accessed by multiple users, create/edit/detail/index should be separated

I have compiled a project management software. Therefore, data of requirements, defects, and tasks in the group can be viewed by multiple people. There are two advantages for separate writing:

1. The update conflict after editing is avoided.

2. It is easy to set permissions. For example, some users can only view tasks that cannot be edited or created, while others can create tasks that cannot be edited.

3. It is easy to use a link as an external interface.

For example, you can put "xxx/stories/create" in the internal OA, And the visitor can create a user story (requirement) by clicking here ). Because it is likely that the sales staff are creating the product, they should not have the permission to browse all the stories, and they would not know where to create the story if they could enter the 10 thousand interface.

For pages accessed by a single user, these views can and tend to be merged.

1. typically, all functions of ADM are required to change all user names to "last. first ", let them click Edit to run a lot of places to complete, it is better to complete in a giant editing interface. There won't be countless ADM members working together, even if they ask for help to work together, they will certainly coordinate in advance, which is safe.

2. "My personal center", this place must be my own. A lot of information in it should be designed based on the principle of convenient and fast, rather than permission management.

3. A very small number of pages that can be operated by team leaders, such as the plan/approval page.

 

This idea is not to use the pre-booking criteria, but to follow the"In that scenario, how to do it is betterIt is estimated that a new rule may be found later, and then it will be added later.

Add some content about the interface layout and product concept.

My later work was to manage the market and sales of software. I encountered many easy-to-use and uneasy-to-use products and found some potential rules.

In early software development, we used to use a single, powerful interface to complete all the work.. For example, Word and Excel can be used almost on a single interface for a whole day, regardless of the user's role. Therefore, when software functions become more and more complex, the difficulty of use also increases sharply.

From a functional perspective, for example, when you use the formula/condition format in an Excel table, the space is very crowded. A very small number of screens serve the current operation.

From the perspective of roles, even simple software such as Word/Excel has roles such as author/reviewer/reader. Their permissions, usage habits, and common operations are completely different. A single interface makes some roles feel uncomfortable.

In recent software development, due to the emergence of web, a single interface has gradually become more inclined to complete a single function.. A variety of websites are typical. For example, Sina, its core functions and code volume may not exceed office, but the number of interfaces is huge, and the effect is: anyone on Sina will not be lost, nor will they feel overwhelmed by the complexity of functions.

From a functional perspective, the advantages of the split interface are:

1. There is almost no need to develop external APIs.

If one interface provides only one function, the interface link is the function API;

2. Permission control is much simpler.

If an interface contains many functions, it is a complicated task for a login user to operate or not to operate. A lot of work needs to be done in the view, now all the work is done in the controller.

From the role perspective, the advantages of the split interface are:

1. Roles view their own content.

Never think that it would be better to give him more content. In the last training class, someone wrote a user story, "as a user, you can log on to the system to view projects and tasks, so that you can ......", The content at that time was "user modeling", which was to find out who would use this function, and the analysis result was: "senior, middle-level, product manager, Project Manager, and team members will all use this story." This is troublesome, because the work content of these people is completely different, and the focus of the content is different. Some people may find this interface inconvenient even if it is designed.

2. Each role operates its own functions.

If some textbox is clearly displayed on the interface, the user may happily fill in some content and press the button: "You have no edit permission", which is very annoying. After the split interface, go to their respective interfaces, and those who do not have the editing permission will not be able to see the textbox.

The disadvantage of splitting the interface is that the batchcompute operation capability is deteriorated. Therefore, if this function is very important, you can try to make a composite interface on the interface for a large number of batch operations, and use jquery's focus function in combination, make an interface that completes the operation with the minimum number of operations.

 

Click to download the free agile development textbook: Martian agile development manual