Code First
-
Entity Framework in agile environment - Design and Architecture Discussion Boards[^] Was reading this thread. Just want to really know, is there really someone who's using Code-first as the standard approach in their project? I've been trying to do this, but somehow the team environment/people rushes towards DB first. Even our boss is not so keen in getting to this :) Is this something we should definitely aspire to achieve or it's okay to continue with DB first approach?
We divide ours out, schema changes are in one story and then the ETL process is another. Schema stories are played first so that the guy doing the ETL has somewhere to stick the new data.
-
Entity Framework in agile environment - Design and Architecture Discussion Boards[^] Was reading this thread. Just want to really know, is there really someone who's using Code-first as the standard approach in their project? I've been trying to do this, but somehow the team environment/people rushes towards DB first. Even our boss is not so keen in getting to this :) Is this something we should definitely aspire to achieve or it's okay to continue with DB first approach?
R1911 wrote:
Is this something we should definitely aspire to achieve
No.
or it's okay to continue with DB first approach?
Yes. Code often enough wants to see the data in a different way than is best for DB performance and normalization. I prefer to implement the DB first and generate the model (classes) from the DB (as partial classes so I can, if necessary, extend them with helpful properties, and either create views in the DB or views in the code from the model. Furthermore, by specifying my DB models myself and using [FluentMigrator](https://github.com/fluentmigrator/fluentmigrator) and a custom tool that I wrote, I can also specify attributes on the fields that drive the UI behavior, like:
{Name: 'IsManager', Type: 'bool', IsDisplayField: true, DisplayName: 'Is Manager?' },Add comments to the metadata, like:{Name: 'IsCommunityStaff', Type: 'bool', Comment: 'For community cash drawer support.'},Specify interfaces that the model should implement, like:{Name: 'Fingerprint', Implements: 'IFingerprint',custom formatting (I'm using DevExpress for the UI controls) like:{Name: 'TaxRate', Type: 'decimal', ActualType: 'Number4', IsDisplayField: true, DisplayName: 'Tax Rate as %', Format: '###0.0000'},
drive lookups implemented as dropdowns like:
{Name: 'DisputeTypeId', Type: 'int', DisplayName: 'Type', FK: 'DisputeType.Id', IsDisplayField: true, LookupModel: 'DisputeType', LookupField: 'Name' },and specify initial load of data when creating the DB from scratch, like:{ Name: 'DisputeType', IsLookup: true, Fields:
[
{Name: 'Id', IsPK: true, Type: 'int', IsIdentity: true },
{Name: 'Code', Type: 'int' },
{Name: 'Name', Type: 'string', IsDisplayField: true },
{Name: 'Description', Type: 'string', Nullable: true, IsDisplayField: true },
],
InitialLoad:
[
{Code: 0, Name: 'Shopper', Description: 'Did not receive products/services, dissatisfied, not refunded, etc.'},
{Code: 1, Name: 'Process Error', Description: 'Charged twice, charged incorrect amount.'},
{Code: 2, Name: 'Fraud', Description: 'Stolen card.'},
{Code: 3, Name: 'Friendly Fraud', Description: 'Customer claims valid purchase was fraudulent, etc.'},
{Code: 4, Name: 'Other'},
]
},and implement custom code generati
-
I don't see why your chosen project management methodology should drive your solution's technology decisions.
F-ES Sitecore wrote:
I don't see why your chosen project management methodology should drive your solution's technology decisions.
It's a good point but also interesting that you see the items I talked about as a separate thing -- as Project Management. Even if there is no official process, no methodology there is still something managing the project -- meaning some process that guides how pieces are completed. It all melts together really. Boundaries like PM, Dev, Test, etc are really false boundaries anyways, created to shove workers into roles that describe what they probably spend their time on.
-
Entity Framework in agile environment - Design and Architecture Discussion Boards[^] Was reading this thread. Just want to really know, is there really someone who's using Code-first as the standard approach in their project? I've been trying to do this, but somehow the team environment/people rushes towards DB first. Even our boss is not so keen in getting to this :) Is this something we should definitely aspire to achieve or it's okay to continue with DB first approach?
The only time I've have to deal with "Code First" was with a lead developer who was scared of SQL due to tooo many run-ins with Little Bobby. Took me almost a year to clean up an database created by LINQtoSQL (pre EF)
Director of Transmogrification Services Shinobi of Query Language Master of Yoda Conditional
-
F-ES Sitecore wrote:
I don't see why your chosen project management methodology should drive your solution's technology decisions.
It's a good point but also interesting that you see the items I talked about as a separate thing -- as Project Management. Even if there is no official process, no methodology there is still something managing the project -- meaning some process that guides how pieces are completed. It all melts together really. Boundaries like PM, Dev, Test, etc are really false boundaries anyways, created to shove workers into roles that describe what they probably spend their time on.
raddevus wrote:
there is still something managing the project -- meaning some process that guides how pieces are completed.
I disagree. Nowhere in the agile manifesto does it dictate what technology you can use, and the belief that agile means no planning\speccing and is about getting things developed "quick" are misunderstandings of agile, and one of its biggest enemies. There is no reason that code first is better for agile than database first, and if your project management is driving your technology then your project management is bad.
-
raddevus wrote:
there is still something managing the project -- meaning some process that guides how pieces are completed.
I disagree. Nowhere in the agile manifesto does it dictate what technology you can use, and the belief that agile means no planning\speccing and is about getting things developed "quick" are misunderstandings of agile, and one of its biggest enemies. There is no reason that code first is better for agile than database first, and if your project management is driving your technology then your project management is bad.
F-ES Sitecore wrote:
Nowhere in the agile manifesto does it dictate what technology you can use,
I agree. I was trying to say that this is Microsoft's attempt to create a technology to help lead devs into this by providing a "design on the fly" type of thing. Design on the fly isn't quite right either and is a variable depending upon the team. Also thinking more about Agile Scrum here. The point is, create one domain model into class model and Code-First it and you are on the steps toward iterative design.
F-ES Sitecore wrote:
There is no reason that code first is better for agile than database first
Also agree. However, as I mentioned Code-First is a dev-first type of view - a technology that is an attempt to make it easier for devs to quickly design using Models and having them serialized to the database. If the dev were to create the DB table first it could be seen as the model and design coming from that too. But devs are more code-centric and it is more common that when someone designs a database they do more than one table at a time -- just a convention.
F-ES Sitecore wrote:
and if your project management is driving your technology then your project management is bad.
I think that this code-first idea has little to do with project management because it is coming from the devs viewpoint. This is probably used more in cases where there is no project management. Which goes back to my original post that I am saying that this whole Code-First thing was a way to lure devs into at least creating models first (very minimal design) and allow them to design one model at a time (iteratively) and is generally so loose that it would be mostly for prototyping or first run design. Also throughout all this I'm not saying that the Agile Principles mean that there is no design. I really like the original Agile Principles[^]. I'm saying that they do say, "Working software is the primary measure of progress." so code-first is an attempt (however good or terrible it may be) to help devs design iteratively to get to running code (serialized to db) as quickly as possible. Also, of course, I am saying that all design is not done up front as another principle states, "Deliver w
-
raddevus wrote:
there is still something managing the project -- meaning some process that guides how pieces are completed.
I disagree. Nowhere in the agile manifesto does it dictate what technology you can use, and the belief that agile means no planning\speccing and is about getting things developed "quick" are misunderstandings of agile, and one of its biggest enemies. There is no reason that code first is better for agile than database first, and if your project management is driving your technology then your project management is bad.
Regrettably, "agile", as used today, is almost devoid of meaning. Its a shame the intent of the original agile manifesto is largely forgotten. It was a simple statement of principles that stressed flexibility not only in design, but also in process. The primary issue I have with current claimants of agility is the rigidity of process. Any objective observation of a flaw results in a reflexive "you're doing it wrong". The mere possibility of any flaw in the process is unacceptable. This is simply dogma and IMHO the exact opposite of the agile manifesto's goal. Oh well...the folks who pay the bills get to call the shots...however counter-productive they may be. I'll keep cashing the checks and wait for this nonsense to pass. Hopefully, it will, before I do :)
-
Regrettably, "agile", as used today, is almost devoid of meaning. Its a shame the intent of the original agile manifesto is largely forgotten. It was a simple statement of principles that stressed flexibility not only in design, but also in process. The primary issue I have with current claimants of agility is the rigidity of process. Any objective observation of a flaw results in a reflexive "you're doing it wrong". The mere possibility of any flaw in the process is unacceptable. This is simply dogma and IMHO the exact opposite of the agile manifesto's goal. Oh well...the folks who pay the bills get to call the shots...however counter-productive they may be. I'll keep cashing the checks and wait for this nonsense to pass. Hopefully, it will, before I do :)
Great post!!
Eric Lynch wrote:
I'll keep cashing the checks and wait for this nonsense to pass. Hopefully, it will, before I do
I'm with you!! The reason I like Agile is : 1. Those original Agile Manifesto Principles are fantastic. They really summarize "how work gets done". 2. I've read the book, Amazon.com: Scrum: The Art of Doing Twice the Work in Half the Time eBook: Jeff Sutherland, JJ Sutherland: Kindle Store[^] three times. The author is one of the two original people who created the Agile Scrum process and the book describes "The Heart of Agile : Getting Stuff Done via process".
-
R1911 wrote:
Is this something we should definitely aspire to achieve
No.
or it's okay to continue with DB first approach?
Yes. Code often enough wants to see the data in a different way than is best for DB performance and normalization. I prefer to implement the DB first and generate the model (classes) from the DB (as partial classes so I can, if necessary, extend them with helpful properties, and either create views in the DB or views in the code from the model. Furthermore, by specifying my DB models myself and using [FluentMigrator](https://github.com/fluentmigrator/fluentmigrator) and a custom tool that I wrote, I can also specify attributes on the fields that drive the UI behavior, like:
{Name: 'IsManager', Type: 'bool', IsDisplayField: true, DisplayName: 'Is Manager?' },Add comments to the metadata, like:{Name: 'IsCommunityStaff', Type: 'bool', Comment: 'For community cash drawer support.'},Specify interfaces that the model should implement, like:{Name: 'Fingerprint', Implements: 'IFingerprint',custom formatting (I'm using DevExpress for the UI controls) like:{Name: 'TaxRate', Type: 'decimal', ActualType: 'Number4', IsDisplayField: true, DisplayName: 'Tax Rate as %', Format: '###0.0000'},
drive lookups implemented as dropdowns like:
{Name: 'DisputeTypeId', Type: 'int', DisplayName: 'Type', FK: 'DisputeType.Id', IsDisplayField: true, LookupModel: 'DisputeType', LookupField: 'Name' },and specify initial load of data when creating the DB from scratch, like:{ Name: 'DisputeType', IsLookup: true, Fields:
[
{Name: 'Id', IsPK: true, Type: 'int', IsIdentity: true },
{Name: 'Code', Type: 'int' },
{Name: 'Name', Type: 'string', IsDisplayField: true },
{Name: 'Description', Type: 'string', Nullable: true, IsDisplayField: true },
],
InitialLoad:
[
{Code: 0, Name: 'Shopper', Description: 'Did not receive products/services, dissatisfied, not refunded, etc.'},
{Code: 1, Name: 'Process Error', Description: 'Charged twice, charged incorrect amount.'},
{Code: 2, Name: 'Fraud', Description: 'Stolen card.'},
{Code: 3, Name: 'Friendly Fraud', Description: 'Customer claims valid purchase was fraudulent, etc.'},
{Code: 4, Name: 'Other'},
]
},and implement custom code generati
I'm curious, do many of your clients development teams adopt this methodology, the level of discipline would need to be quite high. I have fiddled with a number of meta data structures over the years but could never convince a team of junior developers to adopt and adhere to the structures. I ended up with a convention based environment where the first field is a primary key, identity field with the same name as the table +ID. Views with the same name as the table prefixed with vw. All this allows the custom app "ClassBuilder" to generate the procs, DAL and partial UI files from the table/view. ClassBuilder, which I filched in the early 90's, is in use in a number of organisations where I have contracted over the years, primarily because it is relatively simple.
Never underestimate the power of human stupidity RAH
-
I'm curious, do many of your clients development teams adopt this methodology, the level of discipline would need to be quite high. I have fiddled with a number of meta data structures over the years but could never convince a team of junior developers to adopt and adhere to the structures. I ended up with a convention based environment where the first field is a primary key, identity field with the same name as the table +ID. Views with the same name as the table prefixed with vw. All this allows the custom app "ClassBuilder" to generate the procs, DAL and partial UI files from the table/view. ClassBuilder, which I filched in the early 90's, is in use in a number of organisations where I have contracted over the years, primarily because it is relatively simple.
Never underestimate the power of human stupidity RAH
Mycroft Holmes wrote:
do many of your clients development teams adopt this methodology, the level of discipline would need to be quite high.
Good question. Given that I am the development team for several of my clients, I can customize my toolset as I choose.
Mycroft Holmes wrote:
but could never convince a team of junior developers to adopt and adhere to the structures.
Conversely, when I've worked with teams, particularly with junior developers, I learned a lesson a long time ago that you don't rely on them to use and maintain the metadata -- they're just not used to thinking in those terms. But what I found did work, and worked quite well, is to provide a UI designer. Junior devs (and even senior devs) feel more comfortable with a designer, rather than mucking around in the XML, JSON, or whatever. And it also gives management the impression that you're using a professional tool, not some half baked roll-your-own implementation (which is what it is under the hood, hahaha.) At one point (2005 or so), I had co-opted the WinForm designer, added a (quite sophisticated) schema designer, a custom scripting language, and embedded the DevExpress report designer, all UI-based. The management and the devs loved it. A lot of work to hide the fact that all it did was generate XML, but it was worth it.
Latest Article - A Concise Overview of Threads Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny Artificial intelligence is the only remedy for natural stupidity. - CDP1802
-
R1911 wrote:
Is this something we should definitely aspire to achieve
No.
or it's okay to continue with DB first approach?
Yes. Code often enough wants to see the data in a different way than is best for DB performance and normalization. I prefer to implement the DB first and generate the model (classes) from the DB (as partial classes so I can, if necessary, extend them with helpful properties, and either create views in the DB or views in the code from the model. Furthermore, by specifying my DB models myself and using [FluentMigrator](https://github.com/fluentmigrator/fluentmigrator) and a custom tool that I wrote, I can also specify attributes on the fields that drive the UI behavior, like:
{Name: 'IsManager', Type: 'bool', IsDisplayField: true, DisplayName: 'Is Manager?' },Add comments to the metadata, like:{Name: 'IsCommunityStaff', Type: 'bool', Comment: 'For community cash drawer support.'},Specify interfaces that the model should implement, like:{Name: 'Fingerprint', Implements: 'IFingerprint',custom formatting (I'm using DevExpress for the UI controls) like:{Name: 'TaxRate', Type: 'decimal', ActualType: 'Number4', IsDisplayField: true, DisplayName: 'Tax Rate as %', Format: '###0.0000'},
drive lookups implemented as dropdowns like:
{Name: 'DisputeTypeId', Type: 'int', DisplayName: 'Type', FK: 'DisputeType.Id', IsDisplayField: true, LookupModel: 'DisputeType', LookupField: 'Name' },and specify initial load of data when creating the DB from scratch, like:{ Name: 'DisputeType', IsLookup: true, Fields:
[
{Name: 'Id', IsPK: true, Type: 'int', IsIdentity: true },
{Name: 'Code', Type: 'int' },
{Name: 'Name', Type: 'string', IsDisplayField: true },
{Name: 'Description', Type: 'string', Nullable: true, IsDisplayField: true },
],
InitialLoad:
[
{Code: 0, Name: 'Shopper', Description: 'Did not receive products/services, dissatisfied, not refunded, etc.'},
{Code: 1, Name: 'Process Error', Description: 'Charged twice, charged incorrect amount.'},
{Code: 2, Name: 'Fraud', Description: 'Stolen card.'},
{Code: 3, Name: 'Friendly Fraud', Description: 'Customer claims valid purchase was fraudulent, etc.'},
{Code: 4, Name: 'Other'},
]
},and implement custom code generati
-
Entity Framework in agile environment - Design and Architecture Discussion Boards[^] Was reading this thread. Just want to really know, is there really someone who's using Code-first as the standard approach in their project? I've been trying to do this, but somehow the team environment/people rushes towards DB first. Even our boss is not so keen in getting to this :) Is this something we should definitely aspire to achieve or it's okay to continue with DB first approach?
There's a lot of waffle in the responses but the truth is as it is for most things... It depends on what you're developing. Some people have alluded to this. I have worked on projects that have used code first effectively. No performance bottlenecks, easy deployments, very neat code. Easy to follow and all in one place. If you have a fairly simple schema to create, code first is not going to be a problem. If you have a more complex schema, then you may have to evaluate it a bit more. I have worked on projects that code the DB first. This gives you the most control and is the more consisitent approach when writing stored procedures, triggers and other object types. If using Visual Studio (assuming as you're using EF) and if you're also using SQL Server then Visual Studio DB projects are great for modelling databases and doing quick and easy deployments. ORMs are great but use with a little caution as you may introduce unnecessary overheads. In summary, to answer your question more directly, yes code first is used for real applicstions/projects. On the question of whether to aspire to it, I do not believe it should be considered a standard or any sort of evolution of development - you would use it based on the merits for your application.
-
Entity Framework in agile environment - Design and Architecture Discussion Boards[^] Was reading this thread. Just want to really know, is there really someone who's using Code-first as the standard approach in their project? I've been trying to do this, but somehow the team environment/people rushes towards DB first. Even our boss is not so keen in getting to this :) Is this something we should definitely aspire to achieve or it's okay to continue with DB first approach?
We always do code first, but we also follow a very strict and sane DB design principle. "Everything is flat by design and we optimize for lowest complexity." Juniors that optimize for "This is going to be faster and/or more efficient" are getting stabbed with a knife by me personally. People prefer DB first, because they like to decide what the data should look like.. which is also fundamentally wrong. Data already has a defined structure when it gets into your system, and has a defined structure when it comes out. All you need to do is flatten it in a safe way, so you can persistently store it, when it's in between those 2 states. The worst of the bunch are Enterprise folks that go on and on about Business Objects or Domain Objects. They're willfully ignoring their core business (= selling a product or service) in favor of making arbitrary decisions about things they've invented themselves. We call that "having a god complex", because it's fun playing god and creating stuff that people will build for you. I totally get that. But they should do that in Civ5 or something, not at work.
-
This is way too long but your question got me thinking and I just wrote it up. It seems that CodeFirst was a way to get devs to : "Do design in small chunks." Some devs are not going to plan at all. They just start typing code. A lot of those devs were very good at doing this and could really make things happen. But others were terrible at it and created huge maintenance nightmares. So a type of methodology arose out of that which said, "Hey let's make a process out of the idea of typing code. We need to provide a basic process." Just Code It Up In the beginning, many devs just typed code which was imperative in nature -- you tell the code what to do and it does it. Along came OOP. But a lot of devs saw it and just said, "that's a lot of overhead, I can do it faster just by typing up some code" and continued just to "code up a solution". OOP Wave But OOP is about code organization and some people said, "Hey, you need to design things very well and think out everything so you can model the objects in the system and you should have everything planned out so you can go and create the system." But it didn't catch on with a lot of devs because they knew that requirements change and you can't design any large system entirely before building because when you do you miss stuff. But then many devs were like, "Well, we don't want to go back to just coding things up with no plan either." Along Comes Agile Model one domain object and get it working. Get the MVP (minimum viable product) so we can have a bit of design but actually start writing code and having things running very fast. This made the pantsers (coding by the seat of your pants) happy and made the strong OOP devs happier because at least there was some organization and process built into the system. Everything else is just these two factions fighting it out: 1. Pure Agile - (design it on the fly) 2. Heavier process (design more up front / create large domain model ("all" objects in your system)) Reality: Stuck In The Middle Real life is somewhere in between. The Code First thing is a technological process that helps the first group (Pure Agile) to get to what they want with fewer technical barriers. Now they can model an object and it'll be serialized to the database with little work and each time they model a new object their domain model becomes more solid. Of course Code First is also a process that is dev-centric where maybe you have devs that don't have as much experience with dat
-
The bosses always wanted to push the application I am working on to code first. Newer parts work with EF, but there are also more than 20 year old parts that depend on stored procedures. We still need to make changes to the SPs and the data tables. One far away day, when the sun has used up most of its hydrogen and starts to cool down and collapse, we will finaly be rid of all these stored procedures and have EF and the database in a shape that will actually allow code first.
I have lived with several Zen masters - all of them were cats. His last invention was an evil Lasagna. It didn't kill anyone, and it actually tasted pretty good.
EF without "views" and "stored procedures" is like using C# without the .NET framework classes. EF "complements" the database engine; it doesn't "replace" it.
"(I) am amazed to see myself here rather than there ... now rather than then". ― Blaise Pascal
-
Code first is fine for prototyping and knocking out quick things, but it's not suitable for production applications, IMEO.
By definition, a "production" system is past "code first" or "database first"; it's in maintenance mode; which will then probably involve both in one form or another depending on the "fixes" moving forward. A database can have multiple data contexts. A system can have multiple databases. A system "enhancement" can involve adding a new database. Code first or database first?
"(I) am amazed to see myself here rather than there ... now rather than then". ― Blaise Pascal
-
By definition, a "production" system is past "code first" or "database first"; it's in maintenance mode; which will then probably involve both in one form or another depending on the "fixes" moving forward. A database can have multiple data contexts. A system can have multiple databases. A system "enhancement" can involve adding a new database. Code first or database first?
"(I) am amazed to see myself here rather than there ... now rather than then". ― Blaise Pascal
What you described is a production environment, not a production system. By production system I meant an application that is intended to go live and be used in a serious business capacity.
-
Entity Framework in agile environment - Design and Architecture Discussion Boards[^] Was reading this thread. Just want to really know, is there really someone who's using Code-first as the standard approach in their project? I've been trying to do this, but somehow the team environment/people rushes towards DB first. Even our boss is not so keen in getting to this :) Is this something we should definitely aspire to achieve or it's okay to continue with DB first approach?
If starting from scratch, the advantage of "code first" is that the database that is generated "works" with EF. On the other hand, database first assumes you have the smarts to now "confgure" EF to "consume" whatever convoluted schema someone managed to create using "SQL". Now try and keep the 2 in sync. The skill is in knowing when to use which; or both; and transitioning from one to the other.
"(I) am amazed to see myself here rather than there ... now rather than then". ― Blaise Pascal
-
This is way too long but your question got me thinking and I just wrote it up. It seems that CodeFirst was a way to get devs to : "Do design in small chunks." Some devs are not going to plan at all. They just start typing code. A lot of those devs were very good at doing this and could really make things happen. But others were terrible at it and created huge maintenance nightmares. So a type of methodology arose out of that which said, "Hey let's make a process out of the idea of typing code. We need to provide a basic process." Just Code It Up In the beginning, many devs just typed code which was imperative in nature -- you tell the code what to do and it does it. Along came OOP. But a lot of devs saw it and just said, "that's a lot of overhead, I can do it faster just by typing up some code" and continued just to "code up a solution". OOP Wave But OOP is about code organization and some people said, "Hey, you need to design things very well and think out everything so you can model the objects in the system and you should have everything planned out so you can go and create the system." But it didn't catch on with a lot of devs because they knew that requirements change and you can't design any large system entirely before building because when you do you miss stuff. But then many devs were like, "Well, we don't want to go back to just coding things up with no plan either." Along Comes Agile Model one domain object and get it working. Get the MVP (minimum viable product) so we can have a bit of design but actually start writing code and having things running very fast. This made the pantsers (coding by the seat of your pants) happy and made the strong OOP devs happier because at least there was some organization and process built into the system. Everything else is just these two factions fighting it out: 1. Pure Agile - (design it on the fly) 2. Heavier process (design more up front / create large domain model ("all" objects in your system)) Reality: Stuck In The Middle Real life is somewhere in between. The Code First thing is a technological process that helps the first group (Pure Agile) to get to what they want with fewer technical barriers. Now they can model an object and it'll be serialized to the database with little work and each time they model a new object their domain model becomes more solid. Of course Code First is also a process that is dev-centric where maybe you have devs that don't have as much experience with dat
-
DB first usually means there's a "DBA Administrator" in the house; which usually means 6 more months before you "get your database".
"(I) am amazed to see myself here rather than there ... now rather than then". ― Blaise Pascal
Gerry Schmitz wrote:
DB first usually means there's a "DBA Administrator" in the house; which usually means 6 more months before you "get your database".
Very true. The DBA has to get everything right and that takes time. Here's the DBA schedule: 1. 5 months and 3 weeks and 4 days of Candy Crush "work". Must reach level 302!! 2. One day (Friday) of work to design the schema and create the tables on the server. :laugh: :laugh: