How do I avoid ORM tools 'polluting' the model?
-
I have been looking at various ORM libraries. Many of these seem to rely on attributes placed on classes and fields in the model. I understand that attributes can be completely ignored by the build process but I'm not sure how such library-specific attributes fit with the whole idea of dependency injection and being able to swap in/out different data providers without requiring any other changes - and certainly not as 'deep down' as the model layer. I am also puzzled by the workflow using ORM tools. Some require the POCO class to be defined and some ask the data tables to be designed first, but once the first iteration of all this is in a production environment, how on earth do you then instigate any changes without obliterating the live database? I'd be extremely grateful if anyone could point me at some good reading around this whole subject. Kind wishes - Patrick
Thank you to anyone taking the time to read my posts.
-
I have been looking at various ORM libraries. Many of these seem to rely on attributes placed on classes and fields in the model. I understand that attributes can be completely ignored by the build process but I'm not sure how such library-specific attributes fit with the whole idea of dependency injection and being able to swap in/out different data providers without requiring any other changes - and certainly not as 'deep down' as the model layer. I am also puzzled by the workflow using ORM tools. Some require the POCO class to be defined and some ask the data tables to be designed first, but once the first iteration of all this is in a production environment, how on earth do you then instigate any changes without obliterating the live database? I'd be extremely grateful if anyone could point me at some good reading around this whole subject. Kind wishes - Patrick
Thank you to anyone taking the time to read my posts.
In Entity Framework, you can use "fluent configuration" to configure the store, so that you don't need to add library-specific attributes to the classes. Creating and configuring a model - EF Core | Microsoft Docs[^] You can even mix-and-match; I tend to add the non-library-specific attributes like
StringLengthto the classes, and put the EF-specific stuff in anIEntityTypeConfiguration<T>class.Patrick Skelton wrote:
once the first iteration of all this is in a production environment, how on earth do you then instigate any changes without obliterating the live database?
For Entity Framework, you can use migrations to update the database schema to match the model: Migrations Overview - EF Core | Microsoft Docs[^] Other ORMs will probably have something similar. There are also third-party tools to manage your schema migrations (eg: Flyway) but they tend to cost money.
"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer
-
I have been looking at various ORM libraries. Many of these seem to rely on attributes placed on classes and fields in the model. I understand that attributes can be completely ignored by the build process but I'm not sure how such library-specific attributes fit with the whole idea of dependency injection and being able to swap in/out different data providers without requiring any other changes - and certainly not as 'deep down' as the model layer. I am also puzzled by the workflow using ORM tools. Some require the POCO class to be defined and some ask the data tables to be designed first, but once the first iteration of all this is in a production environment, how on earth do you then instigate any changes without obliterating the live database? I'd be extremely grateful if anyone could point me at some good reading around this whole subject. Kind wishes - Patrick
Thank you to anyone taking the time to read my posts.
I use Entity Framework; I like to keep it simple; and have never gone much beyond [KEY]. I maintain my data relationships in code; I use primarily "code-first" versus "data-base" first since I'm primarily developing / prototyping. I think you should examine your own style before subscribing to a particular approach.
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
-
In Entity Framework, you can use "fluent configuration" to configure the store, so that you don't need to add library-specific attributes to the classes. Creating and configuring a model - EF Core | Microsoft Docs[^] You can even mix-and-match; I tend to add the non-library-specific attributes like
StringLengthto the classes, and put the EF-specific stuff in anIEntityTypeConfiguration<T>class.Patrick Skelton wrote:
once the first iteration of all this is in a production environment, how on earth do you then instigate any changes without obliterating the live database?
For Entity Framework, you can use migrations to update the database schema to match the model: Migrations Overview - EF Core | Microsoft Docs[^] Other ORMs will probably have something similar. There are also third-party tools to manage your schema migrations (eg: Flyway) but they tend to cost money.
"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer
Interesting stuff, Richard. Thank you. Looks like I have some reading and experimenting to do.
Thank you to anyone taking the time to read my posts.
-
I use Entity Framework; I like to keep it simple; and have never gone much beyond [KEY]. I maintain my data relationships in code; I use primarily "code-first" versus "data-base" first since I'm primarily developing / prototyping. I think you should examine your own style before subscribing to a particular approach.
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
Thanks, Gerry. Code-first does sound best for me, for the same reasons as you.
Thank you to anyone taking the time to read my posts.
-
I have been looking at various ORM libraries. Many of these seem to rely on attributes placed on classes and fields in the model. I understand that attributes can be completely ignored by the build process but I'm not sure how such library-specific attributes fit with the whole idea of dependency injection and being able to swap in/out different data providers without requiring any other changes - and certainly not as 'deep down' as the model layer. I am also puzzled by the workflow using ORM tools. Some require the POCO class to be defined and some ask the data tables to be designed first, but once the first iteration of all this is in a production environment, how on earth do you then instigate any changes without obliterating the live database? I'd be extremely grateful if anyone could point me at some good reading around this whole subject. Kind wishes - Patrick
Thank you to anyone taking the time to read my posts.
Patrick Skelton wrote:
and being able to swap in/out different data providers without requiring any other changes
Having spent decades working with data providers that is pipe dream. If the system evolves into any complexity then differences between systems will crop up that at best will exhibit problems that make at least one service provide behave in a less than optimal way compared to others. This can be minimized, but not eliminated, by the following 1. Very carefully review all requirements BEFORE committing to evaluate impact on data flows especially those that have any chance of involving performance (volume and size.) The impact must always be rigorously sized. 2. Have a custom data layer that STRICTLY enforces the data rules. 3. Do not allow any exceptions. If you allow even one exception then over time there will be more exceptions.
