My biggest criticism of the Golden Ocean's "Framework" is its tight coupling. Is it possible that it is convenient and loosely coupled?
First, sort out the current needs of the Ocean:
(1) try to drag with the mouse, and the operation is as simple as possible
(2) Permission management should be integrated. Different permissions have different items and can perform different operations.
(3) integration verification required
(4) You must have a control panel similar to the Treeview.
(5) There must be a list of items in list mode, with pagination
(6) There must be a single item viewing, modifying, and inserting in detaillist or formview mode.
(7) powerful search box
(8) Customer requirements have changed and must be easily changed
On this basis, I will add a few more:
(1) loose coupling
(2) layered
If I were in the ocean, I would design this system like this. It's no surprise that I don't have time coding. I don't have that complicated requirement. I have enough ASP. NET controls to use, and I don't have the motivation to code them.
System Structure:
The system is divided into four views, which must be developed by yourself, similar to the existing ASP. NET views. The specific functions are described later,
Responsibilities:
(1) filters are responsible for permission control. This permission control is divided into three aspects:
A) control the items displayed in the listview. The number of items displayed by different people is different. This is the first step of filtering.
B) controls the visibility of Object Attributes on users. This is the second step of filtering.
C) control users' behaviors and filter the standard behaviors of the Four Views
(2) datasource is responsible for providing data and standard behavior, and datasource is also responsible for providing entity metadata to the IDE, so that the IDE can easily generate the view part.Code
(3) view is displayed.
(4) database and linq2sql will not be mentioned
Here are four views:
(1) Dynamic View
This is similar to formview, but can be dynamically generated according to the filter. In essence, it is a formview with a step traversal filter. Find the child controls corresponding to the unauthenticated attributes and remove them from dynamicview.
(2) listview
This adds a filter to the existing listview.
(3) Treeview
You have to develop a new one. Design a standard interface for tree-type data structures, filter nodes, and generate a visible UI.
(4) searchoptionsview
This data source is an object class, which is displayed to users according to the filter. Then dynamically construct the query expression. (It seems that it is a little difficult to use LINQ. If you are not familiar with LINQ, it may be a technical risk. You can use dynamic compilation technology ).
Let's take a look at the implementation of the requirement:
L drag the mouse as much as possible, and the operation should be as simple as possible: database modeling-> Biu generates the database-> vs drag, Biu generates the LINQ layer, then drag datasource, drag view, and Biu. Filters can also be generated by the database permission table. All the above controls can be generated in BIU.
L permission management should be integrated. Different permissions have different items and can perform different operations: filters are responsible
L integration verification: I didn't talk about it earlier. Let's see which step to add or directly configure attributes on the entity.
L there must be a control panel similar to Treeview:
L there must be a list of items in list mode, with pagination: Yes
L there must be a single item viewing, modifying, and inserting in detaillist or formview mode: Yes
L powerful search selection box: Yes
L customer requirements have changed and must be easily changed
Add a field-write an SQL statement and throw it into the database. Add an attribute to the object class and match it;
Delete fields-Change Database and object class
Field name-attributes of the object class
......
L loose coupling: Yes
L layered: Yes
Comments:
(1) compared with the original architecture of golden ocean, it may be a little more complicated. You can perform the main operations only with the mouse, but the elasticity is much larger. The UI Layer of the original architecture is too restrictive.
(2) The decoupling is thorough and the layers are clear. Who knows the benefit. In addition, decoupling and layering will not increase the workload. It's all about biubiubiu. (Altman !)
(3) clear responsibilities and good maintenance
(4) data separation-databases are databases, metadata is metadata, and UI data is the UI data, which is not mixed together. In this way, it is better to build different languages or adopt other tricks, leave enough space
(5) The four views can also be used separately, which has a wide applicability.
How can we coordinate the relationships between the four views? Write a few mediator to implement the most common scenarios.
The above statements are lightweight and not easy to implement. : P