Step by step build a shelf (Model inheritance and factory layer) Step by step build a shelf (analysis) How should we design a database (3) (continued)

I have always felt that simplicity is also a kind of beauty, so is the architecture, and so is the case for human beings.

For ease of understanding, the source code is released here: Click here to download

We strongly recommend that you read this article with the Code. After all, code is the best way for programmers to communicate.

 

Previous articles analyzed the system and drew a sketch of the architecture. For details, see "step by step (analysis)".

The implementation of the modelbase layer and the model layer is simple, so I will not repeat it again. Just go to the code. For the idea of model inheritance, see: how to design a database (3) (continued)

Modelbase code:

namespace ModelBase{    public class Identifier    {        [Key]        public Guid ID { get; set; }    }    public class TeacherBase : Identifier    {        [StringLength(50)]        public string UserName { get; set; }        [StringLength(50)]        public string Pwd { get; set; }    }    public class ContactBase : Identifier    {        [Required]        public Guid TeacherID { get; set; }        [StringLength(50)]        public string Phone { get; set; }        [StringLength(50)]        public string Email { get; set; }    }}

We can see that the data has not been combined at this layer; then the Model Code (assuming it is provided to a school ):

namespace Model.A{    public class Teacher : TeacherBase    {        [StringLength(50)]        public string FirstName { get; set; }        [StringLength(50)]        public string LastName { get; set; }        public Contact Contact { get; set; }    }    public class Contact : ContactBase    {        public DateTime CreateTime { get; set; }    }}

We can see that the teacher contains the contact. I often call it "Data coupling together", although I don't know if this method is correct. Leave a message to correct this statement.

Note that the namespace of model. A is used to distinguish between models. For the model of school B, write the following:

namespace Model.B{    public class Teacher : TeacherBase    {        [StringLength(50)]        public string Number { get; set; }    }    public class Contact : ContactBase    {    }}

We can see that the Model names of school A and school B are both teacher and contact, which are distinguished by different namespaces.

 

Then the implementation of dbcontext:

Using system. data. entity; using model. a; namespace dbaccess. A {public class context: dbcontext {public context () {// This. configuration. autodetectchangesenabled = false; // This. configuration. lazyloadingenabled = true; // This. configuration. proxycreationenabled = false; // This. configuration. validateonsaveenabled = false;} public dbset <teacher> teacher {Get; set;} public dbset <contact> contact {Get; set;} protected override void onmodelcreating (dbmodelbuilder modelbuilder) {modelbuilder. entity <teacher> (). ignore (O => O. contact); // The contact in teacher is not mapped to the database }}}

 

Then there is the difficulty in the system: the design of factory

At the beginning, I thought this was the application scenario described by the abstract factory model: development of different product families of similar products

However, in the actual development process, it is found that the abstract factory cannot meet the needs. Abstract Factory requires subclass to be derived from the base class. Our model is derived from modelbase and meets the conditions. However, different models have their own get/set methods, however, these unique methods cannot be implemented through the abstract factory.

Simple reflection cannot meet the requirements. The reflected object type can only be used after being converted using the as keyword, for example:

Object OBJ = assembly. Load (""). createinstance (""); // assume that a teacher Teacher = OBJ as teacher is reflected here; // you can use it only after the as is required.

 

I spent more than a week on this issue until one day, inspired by the following: You can use pre-compiled commands to implement namespace switching.

#define A#if Busing Model.B;using DBaccess.B;#endif#if Ausing Model.A;using DBaccess.A;#endif

In this case, we only need to change # define a to # define B to switch the model.

The specific implementation of factory is as follows:

#region NameSpace#define A#if Busing Model.B;using DBaccess.B;#endif#if Ausing Model.A;using DBaccess.A;#endif#endregionusing System.Collections.Generic;namespace Factory{    public class ModelFactory    {        public static Teacher GetTeacher()        {            return new Teacher();        }               public static Contact GetContact()        {            return new Contact();        }       }    public class ModelListFactory    {        public static IList<Teacher> GetTeacherList()        {            return new List<Teacher>();        }        public static IList<Contact> GetContactList()        {            return new List<Contact>();        }    }    public class ContextFactory    {        public static Context GetContext()        {            return new Context();        }    }}

The factory is implemented in the simplest factory mode like its name.

 

Put aside

 

PS: It's a new day. All park friends remember to keep warm and cold :)