You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on May 11, 2023. It is now read-only.
Naming conventions in the database are not consistent. The fields are Pascal Case but the tables are Lower Case. In the previous chapters, tables and fields were both Snake Case. I think in this chapter it should at least follow the Pascal Case naming convention consistently.
Passwords in the connection string may trip security bot warnings when the students check in their code to GitHub. I don't have a good AND easy way around this. If it was SQL Server on Windows we could change the type of connection to Integrated Authentication and not need a user name and password. In this case, the proper way to handle this connection with a password is with an App Secret.
Thank you for using Id and not ID. That's just a personal pet peeve of mine. ;)
As a best practice, students should be using SaveChangesAsync and not SaveChanges, but that may be beyond the scope of this course. Maybe worth mentioning as a note?
Another best practice that is not mentioned for web apps is to always use .AsNoTracking when retrieving data that is not going to be updated which is most of the time. This adds a large amount of overhead in EF when populating lists.
The text was updated successfully, but these errors were encountered:
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Naming conventions in the database are not consistent. The fields are Pascal Case but the tables are Lower Case. In the previous chapters, tables and fields were both Snake Case. I think in this chapter it should at least follow the Pascal Case naming convention consistently.
Passwords in the connection string may trip security bot warnings when the students check in their code to GitHub. I don't have a good AND easy way around this. If it was SQL Server on Windows we could change the type of connection to Integrated Authentication and not need a user name and password. In this case, the proper way to handle this connection with a password is with an App Secret.
Thank you for using Id and not ID. That's just a personal pet peeve of mine. ;)
As a best practice, students should be using SaveChangesAsync and not SaveChanges, but that may be beyond the scope of this course. Maybe worth mentioning as a note?
Another best practice that is not mentioned for web apps is to always use .AsNoTracking when retrieving data that is not going to be updated which is most of the time. This adds a large amount of overhead in EF when populating lists.
The text was updated successfully, but these errors were encountered: