June 26, 2020 at 4:16 pm
We have a handful of deprecated columns in a table that is referenced by multiple applications. We were going to remove these columns but there are a couple legacy modules that still reference them and these are not going to be changed. So we're going to leave the columns in the table but we don't want any current or new code to build them into the EF models. I don't work with EF but i'm pretty sure you can manually exclude them however people may forget to do this.
Eventually we want them removed completely.
Does anyone know if there is a way to indicate to EF to not include a column by setting a database property such as adding an extended property to a column or by some other method?
Thanks
June 26, 2020 at 5:07 pm
https://docs.microsoft.com/en-us/ef/core/modeling/entity-properties
Reading through that it sounds to me like EF doesn't support excluding columns when reading the database side of things BUT quick googles indicate that you can exclude a column from a set in EF. You can mark things as not required by making them nullable on the database side, but that doesn't stop EF from pulling that column in.
What you could do is create views that exclude the columns you don't want included or stored procedures that exclude those columns and have the developers work with the views and stored procedures rather than with the tables directly.
At my workplace, all of our C# .NET code is required to call stored procedures to get their data. This allows us to restrict and tune the queries run against the database. It is far too easy to have C# code that is running a slow query against the database (poorly written TSQL, grabbing all the data without a filter and filtering application side, grabbing all of the columns in a table when they only need 1), so we let the database developers handle the TSQL and the application developers handle the C#. This also allows us to test performance with SQL Server upgrades without needing permissions and knowledge on how the application works. We just need to review the stored procedure and run it with valid and invalid parameters to gauge performance.
The above is all just my opinion on what you should do.
As with all advice you find on a random internet forum - you shouldn't blindly follow it. Always test on a test server to see if there is negative side effects before making changes to live!
I recommend you NEVER run "random code" you found online on any system you care about UNLESS you understand and can verify the code OR you don't care if the code trashes your system.
Viewing 2 posts - 1 through 1 (of 1 total)
You must be logged in to reply to this topic. Login to reply