Asp. Net large project practice (3)-Object Modeling in the business field

Are you tired of matching the Model or Entity of database tables?
OK ~ Now let's try to design our business entity classes with the object-oriented idea ....
 
Note: I am not saying how bad this approach is with the one-to-one Model of database tables, because after all, the table-driven design Model has been very active since so many years of practice. I have also used this design for many years, but I have been wondering why the object-oriented programming ideas promoted by the experts are almost useless when dealing with the business? So here we will make a new attempt, maybe because of various specific implementation technical restrictions and my level is limited, this attempt may not be thorough...

1. According to international practice, we create an abstract class, which serves as the base class of all business objects in our system. In the future, we can identify which classes are our own business object classes.
    

      Namespace Demo. HIS. FrameWork. DomainBase
   {
   /// <Summary>
   /// Base class to be inherited by all business classes of the system
   /// </Summary>
   [Serializable]
   Public abstract class BaseObject
   {
   }
   }

    

2. Generally, in the information management system, most business objects need to be persistent to the database. Therefore, we create an abstract class as the base class inherited by all business objects that can be persisted.
   Code

      Namespace Demo. HIS. FrameWork. DomainBase
   {
   /// <Summary>
   /// The base class that can be persisted to the business class of the database.
   /// </Summary>
   Public abstract class Entity: BaseObject
   {
   Public Entity ()
   {
   Id = Guid. NewGuid (). ToString ();
   CreateTime = DateTime. Now;
   IsDelete = false;
   }
   Public virtual string Id {get; protected set ;}
   Public virtual DateTime CreateTime {get; protected set ;}
   Public virtual bool IsDelete {get; set ;}
   Public virtual Int32 Version {get; protected set ;}
   }
   }

   A. Entity inherits BaseObject. Because Entiy is also a business object, it is only a persistent business object.
   B. Why do all attributes use virtual? Because we need to use nhib.pdf for persistence, it requires the attribute to be virtual. If you want to ask why nhib.pdf needs to use virtual, as far as I know, nhib.pdf is transplanted from Java's Hibernate, in Java, virtual is the norm, so it is used for convenience of transplantation... in fact, even if nhib.pdf does not require virtual, I will write it as virtual .... in this way, sub-classes can be rewritten, isn't it so coorse ....?

   C. all objects that can be persistently stored in the database have the Id attribute. Do not tell us that the table in the database does not have the Id field as the primary key (in special cases, there may be no... for example, multiple-to-multiple join tables ). Why is the data type of my Id string? The project is very large and has a long life cycle. It is not certain when the Id data type needs to be changed for some reason (I have met it ...) therefore, we do not set the Id data type to int or guid, and place the Id Generation Method in the constructors of this base class. Note that Id = Guid. newGuid (). toString (); here, the Id generation method uses GUID.

   D. to prevent accidental deletion and program errors caused by table Association, the default deletion in our system is generally logical deletion, therefore, use the IsDelete field for identification (this may produce a lot of junk data, and we can avoid expired deletion, transfer, and other functions in the future ).
   The e. Version field is provided to NHibernate for concurrent processing.
   F. What is the use of CreateTime? I don't know either ....

3. InputItem
   Various drop-down options are often used in our projects, and the customer requirements are BT. The number of options for selection may vary from a few to tens of thousands, and fuzzy Chinese characters are required for quick entry, encoding, Pinyin, and five strokes can be used to retrieve the desired item, for example (this is implemented using EXT for B/S ):
   
   So we want to create a base class for all objects in the system that require such input:

   Code

      Namespace Demo. HIS. FrameWork. DomainBase
   {
   /// <Summary>
   /// Drop-down object
   /// </Summary>
   Public abstract class InputItem: Entity
   {
   Private string name;
   Private string code;
   /// <Summary>
   /// Text Value
   /// </Summary>
   Public virtual string Name
   {
   Get
   {
   Return this. name;
   }
   Set
   {
   If (String. IsNullOrEmpty (value ))
   Throw new NotNullException ();
   This. name = value;
   }
   }
   /// <Summary>
   /// Encoding
   /// </Summary>
   Public virtual string Code
   {
   Get
   {
   Return this. code;
   }
   Set
   {
   If (String. IsNullOrEmpty (value ))
   Throw new NotNullException ();
   This. code = value;
   }
   }
   /// <Summary>
   /// Mnemonic code
   /// </Summary>
   Public virtual string InputCode1 {get; set ;}
   /// <Summary>
   /// Mnemonic code 2
   /// </Summary>
   Public virtual string InputCode2 {get; set ;}
   /// <Summary>
   /// Note 3
   /// </Summary>
   Public virtual string InputCode3 {get; set ;}
   }
   }

   NotNullException is the exception class I have defined. You can skip it for the moment.
   With this class, for example, the "Service Project class", we can write: Code

      Namespace Demo. HIS. Infrastructure. Core
   {
   /// <Summary>
   /// Service Project
   /// </Summary>
   Public class ServiceItem: InputItem
   {
   // ServiceItem attribute 1
   // ServiceItem attribute 2
   }
   }

    

4. Application Scenario example: User
   For example, in our project, the user roles that may log on to our system may include doctors, nurses, patients, and hospital administrators. All these users should belong to the system users.
   Therefore, we can create a User abstract class that contains basic attributes such as username and password, and contains some system User methods such as logon, logout, and password modification ....
   Then, for doctors, nurses, patients, and hospital administrators, these objects are created to inherit the User abstract class, and their objects contain their respective attributes and methods.
   I will not post the specific code. I will talk about it later in this series...

In the future, our business objects will be designed according to this idea. Compared with the previous monotonous entity classes that correspond to database tables in a one-to-one manner, isn't the writing more OO and interesting?

The big theory is everywhere. At least I personally think that writing like this is a bit of a sense of design, and I have a lot better ability to cope with changes in demand.