Discuss Classroom Model about otriples

[mykjar]

I think there should be Capacity (seating places?) property there.
Additionally maybe some information on classroom being capable of audio / video / any-other-tech ?

[mykjar]

I would say that it is worth changing Location property from string to class with corresponding properties (Building, Floor, ect.) as there might be multi building / multi floor + it might will be necessity if there would be scheduling / booking / availability service in future.

[chaouanabil]

@tajwal @mykjar, a table also a good choice. i prefere enum over string property and table (Entity) over enum.

[HatemGamal]

I think there are two kinds of status we should consider, one represents whether the room is active or not, meaning the room can't hold a class yet for cases such as room maintenance, refurbishment, or under construction. The other status defines if the room is free or occupied.

[hassanhabib]

Thank you all for your contributions, here's an overview of our Classroom entity model and the assignments this week:

using System;
					
public class Classroom {
	public Guid Id {get; set;}
	public string Name {get; set;}
	public string Location {get; set;}
	public ClassroomStatus Status {get; set;}
	public DateTimeOffset CreatedDate {get; set;}
	public DateTimeOffset UpdatedDate {get; set;}
	public Guid CreatedBy {get; set;}
	public Guid UpdatedBy {get; set;}
}

public enum ClassroomStatus {
         Available,
         Busy,
         InMaintenance,
         Closed
}

Now, let's talk about assignments:

Setup

• Classroom Model Setup & Migrations with EF Core @hiraldesai Monday 12:00 AM - 11:59 PM PST [done]

Broker

• Classroom Broker Select By Id function @HatemGamal by Tuesday 12:00 AM - 11:59 PM PST [done]
• Classroom Broker Select All function @HatemGamal by Tuesday 12:00 AM - 11:59 PM PST [done]
• Classroom Broker Insert function @HatemGamal by Tuesday 12:00 AM - 11:59 PM PST [done]
• Classroom Broker Update function @HatemGamal by Tuesday 12:00 AM - 11:59 PM PST [done]
• Classroom Broker Delete function @HatemGamal by Tuesday 12:00 AM - 11:59 PM PST [done]

Service

• Classroom Service Add function @viralpandya by Wednesday 12:00 AM - 11:59 PM PST [done]
• Classroom Service Modify function @tobidub by Wednesday 12:00 AM - 11:59 PM PST
• Classroom Service Retrieve by Id function @gauriramesh by Wednesday 12:00 AM - 11:59 PM PST [done]
• Classroom Service Retrieve All function @JaAfghan by Wednesday 12:00 AM - 11:59 PM PST
• Classroom Service Delete by Id function @eriadhami by Wednesday 12:00 AM - 11:59 PM PST [done]

Controller

• Classroom Controller Post endpoint @AgentEnder by Thursday 12:00 AM - 11:59 PM PST
• Classroom Controller Get by Id endpoint @devmanzur by Thursday 12:00 AM - 11:59 PM PST [done]
• Classroom Controller Get All endpoint @Mohamad-ali-8 by Thursday 12:00 AM - 11:59 PM PST
• Classroom Controller Update endpoint @chaouanabil by Thursday 12:00 AM - 11:59 PM PST
• Classroom Controller Delete endpoint @devmanzur by Thursday 12:00 AM - 11:59 PM PST [done]

Acceptance Tests

• Classroom Post Acceptance Test @tajwal by Friday 12:00 AM - 11:59 PM PST
• Classroom Update Acceptance Test @tajwal by Friday 12:00 AM - 11:59 PM PST
• Classroom Get All Acceptance Test @tajwal by Friday 12:00 AM - 11:59 PM PST

Contribution Rules:

1. If you have a service task, make sure you commit a failing test, then commit making it pass and so on until your feature is complete (watch this video for reference: https://youtu.be/FLsHIDe3cNs)
2. All CRUD operations now have similar functionality in the StudentService, Teacher and Course Services, Brokers and Controllers - please follow the same pattern and guidelines.
3. This WIP Coding Standard https://github.com/hassanhabib/CSharpCodingStandard will be our guidance, it is a work in progress but it should give you a pretty good idea bout how our code should look like from guidelines and standardization standpoint.
4. Do not start your task before the designated time and make sure you finalize it at the expected time so others can build on top of your work.

If you haven't had an assignment this week please make sure you engage in discussion for next week so I know you are active in this repo and you are going to be able to contribute to the project.

As soon as all these tasks are done, this issue will be closed.

Thank you all from the bottom of my heart <3 for your contributions, if you are stuck or unsure how to do a task, reach out to me literally on any social media platform you like, LinkedIn, Facebook, Whatsapp, Twitter or even Instagram or just ping me on gitter and I will be sure to response within 2 - 4 hours max.

[hassanhabib]

I would say that it is worth changing Location property from string to class with corresponding properties (Building, Floor, ect.) as there might be multi building / multi floor + it might will be necessity if there would be scheduling / booking / availability service in future.

@mykjar that means it would be a related entity, I agree - we should put it in it's own entity, good point.

[tajwal]

You can add ClassromType: auditorium , Laboratory ...

@chaouanabil would that be an enum or just an open string?

@hassanhabib & @chaouanabil , I was thinking that ClassroomType is needed, now if classroom types are more and dynamic then I think it would be better to have a table for ClassroomTypes(Id, Description) with some more property may be added in future, but if its fixed list and not changing then enum would be enough.

[mykjar]

You can add ClassromType: auditorium , Laboratory ...

@chaouanabil would that be an enum or just an open string?

@hassanhabib & @chaouanabil , I was thinking that ClassroomType is needed, now if classroom types are more and dynamic then I think it would be better to have a table for ClassroomTypes(Id, Description) with some more property may be added in future, but if its fixed list and not changing then enum would be enough.

I would second this. Table is better. This kind of data will be change per system use case. Predefined enum is not a best choice.

[hassanhabib]

Mr.@hassanhabib I think it would be better to used table for ClassroomType

@JaAfghan it makes it definitely more extendable to make the types as external entity. I agree.

[eriadhami]

The other status defines if the room is free or occupied.

To define if the classroom is free or occupied, i think will be better to have kind of timetable for each classroom which will include time and subject. Eg classroom 2B on Monday at 9:00-11:30 Math, 14:00-17:00 Biology....

[chaouanabil]

@a-urel if this information is used just in this entity and it hasn't other business rules (as i mentioned , some courses could requiere certain classroomType that give us a business rule when we schedule a couse session in a classroom ). another problem with this solution is where to stock this list of options.

[a-urel]

IMO we shouldn't create an entity if its properties are just id and name. Especially when this name must be localized.
In this case we can simply provide a combo-box with a localized list (eg. from .resx) of items, and allow end-user to enter a value which is not listed. This approach allows us to prevent incorrect entries (w/ auto-complete), as well as provides enough flexibility.

[JaAfghan]

Mr.@hassanhabib I think it would be better to used table for ClassroomType

[hassanhabib]

The other status defines if the room is free or occupied.

To define if the classroom is free or occupied, i think will be better to have kind of timetable for each classroom which will include time and subject. Eg classroom 2B on Monday at 9:00-11:30 Math, 14:00-17:00 Biology....

@eriadhami that would be a related entity, we would call it something like ClassroomSchedule - but definitely something to consider.

[AgentEnder]

@hassanhabib Ended up not quite getting to this today, will get it done asap tomorrow morning if still available

[hassanhabib]

I think there should be Capacity (seating places?) property there.
Additionally maybe some information on classroom being capable of audio / video / any-other-tech ?

@mykjar very good point - keep the good thoughts coming.

[chaouanabil]

You can add ClassromType: auditorium , Laboratory ...

[hassanhabib]

You can add ClassromType: auditorium , Laboratory ...

@chaouanabil would that be an enum or just an open string?

[mykjar]

Simple addition - Accessibility property? I am not sure if this should be just a flag or a list of items. Most likely list of predefined entities (Type, Description, ect.).

[a-urel]

You can add ClassromType: auditorium , Laboratory ...

@chaouanabil would that be an enum or just an open string?

I think string is a better choice. We can provide a predefined (localizable) list without forcing to use them.

[chaouanabil]

@hassanhabib yes, I think enum is better (specialy that i m thinking we could add a relationship between course or couseSession and ClassroomType. i mean some couses should be given in certains ClassroomType ). And about enums, do you have docs giving some best practices to display enums as string (with localization) when querying it.

[tajwal]

You can add ClassromType: auditorium , Laboratory ...

@chaouanabil would that be an enum or just an open string?

@hassanhabib & @chaouanabil , I was thinking that ClassroomType is needed, now if classroom types are more and dynamic then I think it would be better to have a table for ClassroomTypes(Id, Description) with some more property may be added in future, but if its fixed list and not changing then enum would be enough.

I would second this. Table is better. This kind of data will be change per system use case. Predefined enum is not a best choice.

@mykjar I don't have school system experience but I was part of hostel management system where we added separate table for roomtypes and beside having branch's, buildings, floors, there were sections inside each floor and rooms where added to section based on its type, I not sure if is this possible in school system or not, @a-urel may have information about this.

[a-urel]

I think over-normalization is not a good practice. When all we need is to prevent incorrect entries, a list of suggestions (a predefined list and/or most-recently-used items in a combo-box, not enum) is enough.

[mykjar]

I think over-normalization is not a good practice. When all we need is to prevent incorrect entries, a list of suggestions (a predefined list and/or most-recently-used items in a combo-box, not enum) is enough.

So enum with some generic, out-of-the-box, options + possibility to enter value freely?

[hassanhabib]

IMO we shouldn't create an entity if its properties are just id and name. Especially when this name must be localized.
In this case we can simply provide a combo-box with a localized list (eg. from .resx) of items, and allow end-user to enter a value which is not listed. This approach allows us to prevent incorrect entries (w/ auto-complete), as well as provides enough flexibility.

@a-urel I agree - but I think the Classroom model should have more than that - what are your thoughts on what needs to be in a Classroom model?

[hassanhabib]

You can add ClassromType: auditorium , Laboratory ...

@chaouanabil would that be an enum or just an open string?

@hassanhabib & @chaouanabil , I was thinking that ClassroomType is needed, now if classroom types are more and dynamic then I think it would be better to have a table for ClassroomTypes(Id, Description) with some more property may be added in future, but if its fixed list and not changing then enum would be enough.

@tajwal that's a good point - I agree.

[hassanhabib]

Closing this issue in favor of this commit: 1189779