Code First, do you like it?
-
We are thinking about moving from database first, to code first, with our new projects.
-
Neither. I prefer to hand create both. Call me old school, but I don't trust auto created databases or entity layers. Too many times someone makes a "minor" tweak to one or the other and then forgets to regenerate, then you're hosed.
-
We are thinking about moving from database first, to code first, with our new projects.
For my limited experience, what i can tell either way you got to adjust the side you started first. Even with a virtual Database you'll reach the point where you just transferred it and finished the db, then someone is asking for another field. Or at what point you say the app is ready and you can start to set up the Database? I started DB first, adjusted the programm, then the db, then both and so on. Seems like somethings never "finish".
if(this.signature != "")
{
MessageBox.Show("This is my signature: " + Environment.NewLine + signature);
}
else
{
MessageBox.Show("404-Signature not found");
} -
Depends..if someone stops me on the way back to my desk before I had my coffee, I may have to drink a bit of it before I answer their question. :-D
-
We are thinking about moving from database first, to code first, with our new projects.
Spec First, before any of these :-)
-
Neither. I prefer to hand create both. Call me old school, but I don't trust auto created databases or entity layers. Too many times someone makes a "minor" tweak to one or the other and then forgets to regenerate, then you're hosed.
Vark111 wrote:
Too many times someone makes a "minor" tweak to one or the other and then forgets to regenerate, then you're hosed.
I have read, and heard, many stories about this. It is one of our concerns.
-
We are thinking about moving from database first, to code first, with our new projects.
Programmers rarely think correctly in terms of relationships between objects when they do code first. They're usually thinking in terms of denormalized data. Certainly, I do, because it's the denormalized data that I usually want to display to the user. So, that's the first problem with code first. Programmers are typically not very good at figuring out normalization and the nuances of left joins, right joins, one-to-many and many-to-many relationships, at least as to how you'd implement them in a DB. Sure, the code first stuff *should* be able to generate the lookup tables if you define the relationship ordinality correctly, but as others have written, I'd rather have direct control. Even DB people make a mess of relationships. Lastly, there's a weird reality that I can define a decent normalized database, but when I go to use it in the code, I realize that I screwed up understanding some relationship that I thought I understood when creating the DB, but I realize I got wrong when I go actually trying to use it based on the requirements. It's weird that that can happen, but it does, at least in my experience. [tldr:] Neither code first nor database first is the correct approach. It needs to be "code and database together." And code first does NOT get you there. Marc
Imperative to Functional Programming Succinctly Contributors Wanted for Higher Order Programming Project!
-
Just saw a demo online a few days ago, and the "demo guys" were having trouble with some areas with code first, and they were the "experts". So far, I am not entirely convinced that it is a development strategy worth using for the long term. We shall see, I guess.
-
We are thinking about moving from database first, to code first, with our new projects.
For me, it depends on database use. If the database is going to be highly transactional, I would start with the database as the Entity framework won't optimize table structures and indexes like building it by hand would. If it is just a data store, then start with the app first so you can focus on the presentation layer.
if (Object.DividedByZero == true) { Universe.Implode(); }
-
Programmers rarely think correctly in terms of relationships between objects when they do code first. They're usually thinking in terms of denormalized data. Certainly, I do, because it's the denormalized data that I usually want to display to the user. So, that's the first problem with code first. Programmers are typically not very good at figuring out normalization and the nuances of left joins, right joins, one-to-many and many-to-many relationships, at least as to how you'd implement them in a DB. Sure, the code first stuff *should* be able to generate the lookup tables if you define the relationship ordinality correctly, but as others have written, I'd rather have direct control. Even DB people make a mess of relationships. Lastly, there's a weird reality that I can define a decent normalized database, but when I go to use it in the code, I realize that I screwed up understanding some relationship that I thought I understood when creating the DB, but I realize I got wrong when I go actually trying to use it based on the requirements. It's weird that that can happen, but it does, at least in my experience. [tldr:] Neither code first nor database first is the correct approach. It needs to be "code and database together." And code first does NOT get you there. Marc
Imperative to Functional Programming Succinctly Contributors Wanted for Higher Order Programming Project!
Thanks for your feedback. I appreciate it. :thumbsup:
-
If you ever meet me: You won't like me before I had three mugs of strong coffee that day. Just see my signature.. :)
Get me coffee and no one gets hurt!
Light roast (mild flavor), has more caffeine than manly, dark roast. Just saying. :-D Although, I prefer the flavor of a medium roast to a Sumatra, etc..
-
Just saw a demo online a few days ago, and the "demo guys" were having trouble with some areas with code first, and they were the "experts". So far, I am not entirely convinced that it is a development strategy worth using for the long term. We shall see, I guess.
-
Neither. I prefer to hand create both. Call me old school, but I don't trust auto created databases or entity layers. Too many times someone makes a "minor" tweak to one or the other and then forgets to regenerate, then you're hosed.
-
We are thinking about moving from database first, to code first, with our new projects.
Never liked the code first approach. I'm currently working on a project where it used to be code first, so the database was created by code. (due to external factors we now have database first, but that's to long to explain) Whoever did it messed up royally. - Many to many relationships where there should be one to many. - Tables that just don't make sense. - Overly complicated structures. - Datatypes that just don't make sense. - Missing foreign keys. - ... It's a major pain to work with it now (even with database first) due to those things, unfortunately the database can't be changed anymore so I'm stuck with it (some things I can still fix but most I can't, not without rewriting a major part off the code). About 30% of the tables in that db shouldn't even exist so... If you'r going code first make sure you have a good handle on it because if done wrong it can be a nightmare to work with.
Tom
-
We are thinking about moving from database first, to code first, with our new projects.
-
Spec First, before any of these :-)
Avijnata wrote:
Spec First
That goes without saying.
-
Neither. I prefer to hand create both. Call me old school, but I don't trust auto created databases or entity layers. Too many times someone makes a "minor" tweak to one or the other and then forgets to regenerate, then you're hosed.
-
Never liked the code first approach. I'm currently working on a project where it used to be code first, so the database was created by code. (due to external factors we now have database first, but that's to long to explain) Whoever did it messed up royally. - Many to many relationships where there should be one to many. - Tables that just don't make sense. - Overly complicated structures. - Datatypes that just don't make sense. - Missing foreign keys. - ... It's a major pain to work with it now (even with database first) due to those things, unfortunately the database can't be changed anymore so I'm stuck with it (some things I can still fix but most I can't, not without rewriting a major part off the code). About 30% of the tables in that db shouldn't even exist so... If you'r going code first make sure you have a good handle on it because if done wrong it can be a nightmare to work with.
Tom
Tom Deketelaere wrote:
If you'r going code first make sure you have a good handle on it because if done wrong it can be a nightmare to work with.
This is a real concern for us, as well. Thanks for the feedback.
-
Neither. I prefer to hand create both. Call me old school, but I don't trust auto created databases or entity layers. Too many times someone makes a "minor" tweak to one or the other and then forgets to regenerate, then you're hosed.
I like to roll my own too - if you know what you are doing then it works well.
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
-
We are thinking about moving from database first, to code first, with our new projects.
How about being really brave and discarding the relational model altogether[^]? (OK - possibly quite a big leap into the unknown...)