Code First, do you like it?
-
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!
Hm, how does your heart manage with all that caffeine? I'm genuinely curious as I've tried drinking more coffee but it only made my heart beat faster, my mind was still very interested in sleeping. :) Or maybe I haven't developed a tolerance yet - haven't been drinking coffee regularly for too long.
-
We are thinking about moving from database first, to code first, with our new projects.
I was raised with manual DB creation and then creating code that accesses the DB. This worked well with the waterfall model, where (theoretically) no changes would appear after planning and design (on paper) were over. But in recent years, as things became more "agile" (read: people do not want to make decisions, people want to change their mind very often, people just lack knowing the full story) I started to change my mind. We had lots of problems in our application when we were adding fields to an already existing complex DB and then implementing the handling code. Sometimes datatypes were wrong. Sometimes fieldnames were misspelled etc especially when the change was not implemented by just only one person. Another strong point for code-first entities design was the thing with SVN: While we had good practice already with versioning our code, the DB was hard to track in SVN. Ultimately people started to checkin binary backups from SQL Server, but you could not diff them etc. With code-first we now have a singular, unique description of the Db in Plaintext, with matching datatypes and compile-time error checks. Our test cycles are much easier now. BR Florian
-
Whilst I prefer the one's that on sale. :)
"the debugger doesn't tell me anything because this code compiles just fine" - random QA comment "Facebook is where you tell lies to your friends. Twitter is where you tell the truth to strangers." - chriselst "I don't drink any more... then again, I don't drink any less." - Mike Mullikins uncle
what about different flavours of coffee? does it help? Its normal coffee first (medium don't want to shock the heart to early, got work to do), then mid-morning, may be a orange flavoured coffee or cameral. Just received some Chocolate Mint, but not sure I like this one.
-
We are thinking about moving from database first, to code first, with our new projects.
I would not think about it. I would do it. We did it, it is a paradise.
-
We are thinking about moving from database first, to code first, with our new projects.
You mean diving into the code isn't a good idea? Youtube analogy[^]
-
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.
I am not sure how this can happen. If you were using Entity framework, i know this can't happen. EF will inform you that the database and the POCO are out of sync. Also, EF7 is strictly going to be Code first, though you have the option of generating the classes form an already existing db, but after that code first. I think i prefer code first a lot, its very RAD, and migrations allow me to tweak almost anything nowadays.
-
what about different flavours of coffee? does it help? Its normal coffee first (medium don't want to shock the heart to early, got work to do), then mid-morning, may be a orange flavoured coffee or cameral. Just received some Chocolate Mint, but not sure I like this one.
-
BaconSandwichFirst
-
Think of it as #caffeinedrivendevelopment in action.
Anna (@annajayne) Tech Blog | Visual Lint "Why would anyone prefer to wield a weapon that takes both hands at once, when they could use a lighter (and obviously superior) weapon that allows you to wield multiple ones at a time, and thus supports multi-paradigm carnage?"
-
I am not sure how this can happen. If you were using Entity framework, i know this can't happen. EF will inform you that the database and the POCO are out of sync. Also, EF7 is strictly going to be Code first, though you have the option of generating the classes form an already existing db, but after that code first. I think i prefer code first a lot, its very RAD, and migrations allow me to tweak almost anything nowadays.
Layinka wrote:
EF7 is strictly going to be Code first
Good to know.
-
We are thinking about moving from database first, to code first, with our new projects.
My initial question is why? What are you going to gain? Etc..
-
We are thinking about moving from database first, to code first, with our new projects.
I like Break Before and After Code
-
We are thinking about moving from database first, to code first, with our new projects.
No, I love it. Bearing in mind that my application client base is small-to-mid organizations and so I'm not as concerned with specific database optimizations. And as a dev on a small team I'm just fine with that, because POCOs support my notion that a database is just where I keep my stuff. The primary motivator, on my side, is that they make Abstracting the DAL trivial. If we choose to move to Mongo or Couch at some point, I can just re-implement my IDataContext rather than re-write every single model. I only have 2 real gripes: first is that my preferred TPT hierarchy can result in some very hard to debug queries, and switching from int to GUID indexing can be a giant pain in the rear.
-
No, I love it. Bearing in mind that my application client base is small-to-mid organizations and so I'm not as concerned with specific database optimizations. And as a dev on a small team I'm just fine with that, because POCOs support my notion that a database is just where I keep my stuff. The primary motivator, on my side, is that they make Abstracting the DAL trivial. If we choose to move to Mongo or Couch at some point, I can just re-implement my IDataContext rather than re-write every single model. I only have 2 real gripes: first is that my preferred TPT hierarchy can result in some very hard to debug queries, and switching from int to GUID indexing can be a giant pain in the rear.
Nathan Minier wrote:
I only have 2 real gripes: first is that my preferred TPT hierarchy can result in some very hard to debug queries, and switching from int to GUID indexing can be a giant pain in the rear.
but obviously this is not so great a hindrance, that you don't use code first.
-
Nathan Minier wrote:
I only have 2 real gripes: first is that my preferred TPT hierarchy can result in some very hard to debug queries, and switching from int to GUID indexing can be a giant pain in the rear.
but obviously this is not so great a hindrance, that you don't use code first.
They're gripes, not deal-breakers. I enjoy the ability to abstract the DAL in this way, it just makes sense to me and the flexibility is nice. I forgot to mention earlier, a lot of the specific tweaking can also be separated from the Model using the Fluent API. You can apply all sorts of configurations and settings in the OnModelCreating() function of a DbContext, although I prefer to use a derivative of the EntityTypeConfiguration to tag classes for export, configure the SQL properties, and let MEF figure it out :)
-
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.
It's a step in the right direction. You should not be picking your database early on in the project, that's an architectural decision that could have a lasting impact, and cause lots of headaches. In my experience starting with the DB leads to poorly designed classes. Design/model the problem, then figure out how you want to store it. You should watch this video by Uncle Bob: Robert C. Martin - Clean Architecture on Vimeo[^] Basically, you want to focus on the business model/problem and defer a lot of these big architectual decisions until you get a good understanding of the problem. Eventually you want to get to just a design/modeling phase, where you get the "business owners" and "technical owners" talking in one room, and hashing it out together. No code involved here, just whiteboard and lots of talking.
-
I still prefer to design the database the traditional way, but the migrations that code first uses are pretty cool.
I built a large project with code first using MS MVC (a couple of years ago) and felt that I addressed one of the major problems in programming. One of my basic rules of project development has been YOU BETTER GET YOUR DATABASE DESIGNED FIRST OR YOU WILL REALLY DESTABILIZE THE APP WHEN YOU MAKE CHANGES TO THE DB MIDSTREAM. Sometimes, however, you just don't have that luxury and Code First really helps in that scenario. With code first you focus on your classes and so you can work and think at a truly theoretical level. Changes to classes and new classes migrate to the DB at the push of a button and so there is never any lag between design and implementation when making design changes. That is the high level view. You are free to work and think at a class level. The companion to code first is LINQ. With code first and LINQ you can literally design and built a complex system and never even look at the database. It is a very cool experience. There are some considerations. The key one is test data. When you 'recycle' your DB after class / design changes you often need to migrate test data. When I was working on my code first project, MS had some data migration hooks but I just ended up building a routine to re-populate the test data. I am sure it is better now. I felt Code First was a useful technique when building a system from the ground up.
-
Not really, no. It feels better to start with but when you have a decent size model you basically have no way to visualise it except turning it into a database and then looking at that.
I have seen the many-tentacled monsters manifested from the murky depths of Code First. Epi's with their SAS armor fear to step within the shadow of these Lovecraftian beasts. The Oracles on high, throw ever more power against it, and the leviathan will not be sated. When it takes 109 left joins, 20 sub-selects and 17 decodes to pull a single death record, there is nothing but eye-clawing madness and sound of your own screaming. So... no. I do not like Code First.
-
It's a step in the right direction. You should not be picking your database early on in the project, that's an architectural decision that could have a lasting impact, and cause lots of headaches. In my experience starting with the DB leads to poorly designed classes. Design/model the problem, then figure out how you want to store it. You should watch this video by Uncle Bob: Robert C. Martin - Clean Architecture on Vimeo[^] Basically, you want to focus on the business model/problem and defer a lot of these big architectual decisions until you get a good understanding of the problem. Eventually you want to get to just a design/modeling phase, where you get the "business owners" and "technical owners" talking in one room, and hashing it out together. No code involved here, just whiteboard and lots of talking.
Josh Go wrote:
you want to focus on the business model/problem and defer a lot of these big architectual decisions until you get a good understanding of the problem.
:thumbsup: