locked
when virtual keyword is used in c# ? RRS feed

  • Question

  • in many mvc application i have seen people use virtual keyword. i like to know the reason.

    i have seen a video from this url https://www.youtube.com/watch?v=BSgAA8y5ViU which generate UI from model with scaffolding

    so see this code first

        public class Student
        {
            public int StudentId;
            public string StudentName;
            public int CourseId;
            public virtual Course Courses { get; set; }
        }
    
        public class Course
        {
            public int CourseId;
            public string CourseName;
            public string Description;
            public ICollection<Student> Students {get;set;}
            public ICollection<Lecture> Lectures { get; set; }
        }
    
        public class Lecture
        {
            public int LectureId;
            public string LectureName;
            public int CourseId;
            public virtual Course Courses { get; set; }
        }

    1) why lecture and student class has common property called CourseId ?

    2) see below code

            public ICollection<Student> Students {get;set;}
            public ICollection<Lecture> Lectures { get; set; }

    why they use ICollection ? they can use here list etc ?

    3) why Courses property has been declared with virtual keyword in lecture and student class ?

    please help me to understand the real use of virtual keyword

    public virtual Course Courses { get; set; }

    in what kind of scenario we use virtual keyword ? what is advantage ?

    virtual keyword is used when people use scaffolding to generate UI from model ?

    virtual keyword has any good use when people develop apps with winform ?

    please answer points wise in details.

    thanks

    Wednesday, August 3, 2016 11:06 AM

Answers

  • Hi Mou_inn,

    I will try to answer your questions.

    1) "why lecture and student class has common property called CourseId ?"

    That is a 1:n relationship. A lecture can have a Course and a course can have multiple lectures. A Student can have a course and a course can have multiple students. (The last one does not make much sense, because I would have expected a n:m relationshio here where a student can have multiple courses, too.)

    2) "why they use ICollection ? they can use here list etc ?"

    When writing code, you should be as generic as possible. Of course you could use a concrete class, too. But then your implementation would be fixed to that. The ICollection just defines the interface so you can use any implementation of ICollection. 

    3) "why Courses property has been declared with virtual keyword in lecture and student class ?"

    The virtual keyword is used if you want to offer the option that derived classes can override the current implementation. With just the currently given code, it does not make a difference. The difference will come when it is overridden. 

    With kind regards,

    Konrad

    • Proposed as answer by Hart Wang Friday, August 5, 2016 5:54 AM
    • Marked as answer by Sudip_inn Friday, August 12, 2016 3:13 PM
    Wednesday, August 3, 2016 11:27 AM

All replies

  • You have several questions here.

    1) The CourseId is obviously the Id of the course. It is also a property of the Student so you can identify which course the Student is on. In other words, Student.CourseId is a 'foreign key'.

    2) Using ICollection is just more general. The Course class doesn't care what specific type of list is being used to hold the set of Students and Lectures. It only cares that it has a collection. As long as it only needs the functionality provided by the ICollection interface then this is preferable. It means the code that actually creates the lists can change from using an array to a List or whatever if necessary without breaking the Course class.

    3) Have a look at the documentation. It just means that this function can be overridden if required by a derived class (do you know how inheritence works in an object-oriented language?).

    Wednesday, August 3, 2016 11:21 AM
  • Hi Mou_inn,

    I will try to answer your questions.

    1) "why lecture and student class has common property called CourseId ?"

    That is a 1:n relationship. A lecture can have a Course and a course can have multiple lectures. A Student can have a course and a course can have multiple students. (The last one does not make much sense, because I would have expected a n:m relationshio here where a student can have multiple courses, too.)

    2) "why they use ICollection ? they can use here list etc ?"

    When writing code, you should be as generic as possible. Of course you could use a concrete class, too. But then your implementation would be fixed to that. The ICollection just defines the interface so you can use any implementation of ICollection. 

    3) "why Courses property has been declared with virtual keyword in lecture and student class ?"

    The virtual keyword is used if you want to offer the option that derived classes can override the current implementation. With just the currently given code, it does not make a difference. The difference will come when it is overridden. 

    With kind regards,

    Konrad

    • Proposed as answer by Hart Wang Friday, August 5, 2016 5:54 AM
    • Marked as answer by Sudip_inn Friday, August 12, 2016 3:13 PM
    Wednesday, August 3, 2016 11:27 AM
  • 1) Depends on the requirements. But the most common case: A course consists of lectures, thus it is a parent-child relationship. So that each lecture points to its parent.

    2) Cause in OOP you should use the most generic data type which satisfies you requirements. As it is an interface, a derived course class can use any container class which implements ICollection, but adds value to that derived class. But the course class and its consumers work only on the methods of ICollection. See OOP and inheritance and interfaces.

    3) Cause you should override the Course method in a derived class. See virtual. It's an marker that this method is and should be overwritten. It also uses a different invocation strategy than new. New hides the inherited method. E.g.

    namespace ConsoleCS
    {
        using System;
        public class Program
        {
            public static void Main(string[] args)
            {
                BaseClass baseClass = new BaseClass();
                DerivedClass derivedCass = new DerivedClass();
    
                baseClass.A();
                baseClass.B();
                derivedCass.A();
                derivedCass.B();
    
                // Cause DerivedClass has BaseClass as parent, we can cast it.
                BaseClass derivedClassAsBaseClass = derivedCass;
    
                derivedClassAsBaseClass.A();
                derivedClassAsBaseClass.B();
    
                Console.WriteLine("\nDone.");
                Console.ReadLine();
            }
    
            public class BaseClass
            {
                public void A() { Console.WriteLine("Base A"); }
                public virtual void B() { Console.WriteLine("Base B"); }
            }
    
            public class DerivedClass : BaseClass
            {
                public new void A() { Console.WriteLine("Derived A"); }
                public override void B() { Console.WriteLine("Derived B"); }
            }
        }
    }

    Wednesday, August 3, 2016 11:31 AM
  • in many mvc application i have seen people use virtual keyword. i like to know the reason.

    The simplest approach would be to ask the users. However it is likely a faulty input design. In particular faulty UI scaling would guide most people towards the virtual Keyboard.

    And of course if that Webpage is mostly used on Mobile Phones, users have no option to not use a virtual keyboard.

    MVC is a older designer pattern. While still valid, it is almost exclusively used in Web Application Contexts.
    Web technology related questions are best asked on the ASP.Net Forum:
    http://forums.asp.net/

    Wednesday, August 3, 2016 2:50 PM
  • Hi Christopher,

    I think you missed that he talked about the keyword "virtual" and not about a virtual keyboard.

    With kind regards,

    Konrad

    Wednesday, August 3, 2016 2:52 PM
  • :) ymmd
    Wednesday, August 3, 2016 3:00 PM
  • Hi Christopher,

    I think you missed that he talked about the keyword "virtual" and not about a virtual keyboard.

    With kind regards,

    Konrad

    I realised that just about now. Oddly I have been wondering why that was even in here, considering nothing in there dealt with the Virtual keyboard. I guess brain fart.

    Thursday, August 4, 2016 12:45 AM