Display and storage of information reading status in the Winform development framework.

Display and storage of information reading status in the Winform development framework.

In many projects, you may need to record the reading status of some data. If you have read or not read the data, you must make different identifiers to help you understand the data status. For example, in my customer relationship management system, the customer's status is tracked. If the recent contact time exceeds the configured number of days, it is displayed in particular. In similar application scenarios, there are many applications, such as viewing the status of notification announcements, process records, and internal information. So how can we solve these general requirements? Do we need to set a table for each of them to record these statuses?

1. Application Requirements

As mentioned above, we may need to record the reading status of different users on some data. For example, in my customer relationship management system, for the list of customers who have not been contacted recently, the view status is displayed.

Of course, there may be other similar scenarios in our business system.

For these similar requirements, we can use a table to store the state of these application scenarios. We can design a table TB_InformationStatus to store the state of the data.

The Information_ID above is the ID of the data corresponding to different tables, the Status is the state we need to record, and the User_ID is the corresponding user, so for different business tables, different people can record their data for our processing and display.

2. function implementation

For this information status record table, we need to define several interfaces for information processing.

/// <Summary> /// set the status /// </summary> /// <param name = "UserID"> User ID </param> /// <param name = "InfoType"> information type </param> /// <param name = "InfoID"> information primary key ID </param> /// <param name = "Status"> status: 0 unread 1 read </param> void SetStatus (string UserID, InformationCategory InfoType, string InfoID, int Status ); /// <summary> /// matching status /// </summary> /// <param name = "UserID"> User ID </param> /// <param name = "InfoType"> information type </param> /// <param name = "InfoID"> information primary key ID </param> /// <param name = "Status"> status: 0 unread 1 read </param> // <returns> </returns> bool CheckStatus (string UserID, InformationCategory InfoType, string InfoID, int Status ); /// <summary> /// check whether the specified record has been read /// </summary> /// <param name = "UserID"> User ID </param> // /<param name = "InfoType"> information type </param> // <param name = "InfoID"> information primary key ID </param> // <returns> </returns> bool IsReadedStatus (string UserID, informationCategory InfoType, string InfoID );

We designed the auxiliary table tb_ionionstatus to store the data status, but it does not change the field data of the primary table. However, when we display the data of the primary table, you can perform joint processing.

Take the customer information as an example. The data obtained through joint processing is still a list of customer information, as shown in the following code.

/// <Summary> /// obtain the user's List of recent uncontacted customers /// </summary> /// <returns> </returns> private List <CustomerInfo> GetUnContactList () {string KeyName = "FollowExpireDays"; int FollowExpireDays = config. appConfigGet (KeyName ). toInt32 (); if (FollowExpireDays <1) {FollowExpireDays = 1;} List <CustomerInfo> list = BLLFactory <Customer>. instance. getUnContactList (FollowExpireDays, LoginUserInfo. ID. toString (); return list ;}

At the business layer, we only need to construct our filter conditions to obtain user data and process the data.

Condition. addCondition ("LastContactDate", today. addDays (-1 * FollowExpireDays), SqlOperator. lessThanOrEqual); condition. addCondition ("Deleted", 0, SqlOperator. equal); // The deleted condition is not displayed. addCondition ("Creator", userId, SqlOperator. equal); // select the user's record string where = condition. buildConditionSql (). replace ("Where", ""); List <CustomerInfo> list = baseDal. find (where); foreach (CustomerInfo info in list) {bool readed = BLLFactory <InformationStatus>. instance. isReadedStatus (userId, InformationCategory. customer Contact, info. ID );Info. Data1 = readed? "Read": "unread";}

The Data1 in the code above is the attribute of the base class of our object class. Here we use it to record the state. Otherwise, we need to convert the object class set to the DataTable type.

In this way, the returned data has the reading status of this record. You only need to modify the alias of the Data1 attribute during display.

/// <Summary> /// bind list data /// </summary> private void BindData () {this. winGridViewPager1.DisplayColumns = displayColumns; this. winGridViewPager1.ColumnNameAlias = BLLFactory <Customer>. instance. getColumnNameAlias (); // field Column Display name escape this. winGridViewPager1.AddColumnAlias ("Data1", "view status"); List <CustomerInfo> list = GetUnContactList (); this. winGridViewPager1.DataSource = new WHC. pager. winControl. sortableBindingList <CustomerInfo> (list); this. winGridViewPager1.PrintTitle = "List of uncontacted customers ";}

3. Function Expansion

To display records of different types of customers more effectively, we may need to set a period of 7 days for common customers to follow up, 5 days for VIP customers to follow up, and 3 days for advanced VIP customers to follow up, that is, for the same record, different attribute types may have different requirements.

To meet this requirement, we need to record the data of the customer type and interval days in another table.

Then, when the business logic layer processes and returns Non-Contact customers, it processes them separately and obtains the data for merging, as shown in the following code.

/// <Summary> /// obtain the list of uncontacted customers within the specified interval // </summary> /// <param name = "unContactDays"> and the last contact days interval of the date </param> /// <param name = "userId"> current user </param> /// <returns> </returns> public List <CustomerInfo> getUnContactList (int unContactDays, string userId) {List <CustomerInfo> listAll = new List <CustomerInfo> (); // process each item one by one based on user configuration information, then merge the record List <CustomerAlarmInfo> alarmList = BLLFactory <CustomerAlarm>. instance. findB YUser (userId); foreach (CustomerAlarmInfo alarmInfo in alarmList) {// If advanced query object information exists, use advanced query conditions, otherwise, use the primary table condition to query SearchCondition condition = new SearchCondition (); DateTime today = Convert. toDateTime (DateTime. now. toString ("yyyy-MM-dd"); int FollowExpireDays = alarmInfo. days; if (FollowExpireDays <1) {FollowExpireDays = 1;} condition. addCondition ("Grade", alarmInfo. grade, SqlOperator. equal); condition. A DdCondition ("LastContactDate", today. addDays (-1 * FollowExpireDays), SqlOperator. lessThanOrEqual); condition. addCondition ("Deleted", 0, SqlOperator. equal); // The deleted condition is not displayed. addCondition ("Creator", userId, SqlOperator. equal); // select the user's record string where = condition. buildConditionSql (). replace ("Where", ""); List <CustomerInfo> list = baseDal. find (where); foreach (CustomerInfo info in list) {bool reade D = BLLFactory <InformationStatus>. Instance. IsReadedStatus (userId, InformationCategory. Customer Contact, info. ID); info. Data1 = readed? "Read": "unread";} listAll. AddRange (list);} return listAll ;}

 

For applications in a hybrid architecture, we note that an enumeration parameter (Information category name) is required for the interface. When defining an interface, we need to declare a few parameters, otherwise, errors may occur.

Declare the enumerated objects.

/// <Summary> // information classification /// </summary> [DataContract] public enum InformationCategory {[EnumMember] customer contact, [EnumMember] Notification announcement, [EnumMember] others };

For the defined WCF interface, parameters of the enumeration type must also be specified.

[ServiceContract] [ServiceKnownType (typeof (InformationCategory)] Public interface IInformationStatusService: IBaseService <InformationStatusInfo >{/// <summary> /// set the status /// </summary> /// <param name = "UserID"> User ID </param>/ // <param name = "InfoType"> information type </param> /// <param name = "InfoID"> information primary key ID </param> /// <param name = "Status"> Status: 0 unread 1 read </param> [OperationContract] void SetStatus (string UserID, InformationCategory InfoType, string InfoID, int Status ); /// <summary> /// matching status /// </summary> /// <param name = "UserID"> User ID </param> /// <param name = "InfoType"> information type </param> /// <param name = "InfoID"> information primary key ID </param> /// <param name = "Status"> status: 0 unread 1 read </param> // <returns> </returns> [OperationContract] bool CheckStatus (string UserID, InformationCategory InfoType, string InfoID, int Status ); /// <summary> /// check whether the specified record has been read /// </summary> /// <param name = "UserID"> User ID </param> // /<param name = "InfoType"> information type </param> // <param name = "InfoID"> information primary key ID </param> // <returns> </returns> [OperationContract] bool IsReadedStatus (string UserID, informationCategory InfoType, string InfoID );}

Pay attention to the above, and use enumeration will make everything smooth.

 

NET WinForm how to achieve multi-user login without affecting each other, And the login status can be saved just like the effect of web Session implementation?

Simply save the file locally as an xml file. You can directly read the xml file and deserialize it into an object when necessary. If necessary, you can encrypt and save user information and delete the file when you exit. As for "multi-user login does not affect each other", you do not need to consider this. WinForm is a desktop application and does not have to be used by multiple users at the same time.

Winform button Status display and hide save

When you close the window and open the form again, the system will assign a value again. To display the display information set by the user, you can store the button display information of the current window when the window is closed. When you open the form, read the configuration, and set the display according to the configuration button