Code First, do you like it?

[PIEBALDconsult]

Frack no. It's the epitome of taking a very bad idea and following it ad absurdum.

[PIEBALDconsult]

GuyThiebaut wrote:

if you know what you are doing

Exactly; from what I see, the "latest and greatest shiniest new" tools are designed for a different demographic. :suss: If you don't know what you're doing, better have someone else do it for you.

[Jacquers]

Here is an example click[^] It can generate scripts and apply them to the database based on changes made to the POCO classes used.

[dazfuller]

I do indeed. You need to spend some time ensuring that your entity changes will produce the database design you're expecting (e.g. table-per-class, table-per-hierarchy etc...) and you may want to write some helpers to make adding things like indexes a bit easier but otherwise I've found it to be a very neat way of doing things. One thing to consider though is your initial database creation, for this I'd suggest either having a script to create the database and manage the configuration of it (not my preferred) or create a Database Project and output a DACPAC (much better and has better deployment options if you're using MS SQL Server). The reason for this is that if you use something like EF migrations then you'll get default database settings and sizings when it's created which you may not want, using a DACPAC means you get control over things like collation and recovery modes.

Eagles may soar, but weasels don't get sucked into jet engines

[RUs123]

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.

[Flo Lee]

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

[SPoss]

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.

[dietmar paul schoder]

I would not think about it. I would do it. We did it, it is a paradise.

[Quirkafleeg]

You mean diving into the code isn't a good idea? Youtube analogy[^]

[Layinka]

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.

[xiecsuk]

SPoss wrote: Just received some Chocolate Mint Ooooh, I just love After Eight Chocolate Mints. That thin layer of dark chocolate hiding the peppermint cream filling. Gorgeous!!!

[xiecsuk]

But then you would being from the right side of the Pennines!! That's if I read your signature right. And like me, I suppose it's tea during the day with a single cup of coffee after one's evening meal.

[Anna Jayne Metcalfe]

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?"

[Slacker007]

Layinka wrote:

EF7 is strictly going to be Code first

Good to know.

[boarderstu]

My initial question is why? What are you going to gain? Etc..

[User 12206071]

I like Break Before and After Code

[Nathan Minier]

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.

[Slacker007]

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]

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 :)

[PSU Steve]

Old school here too. I can't recall the last time I let either DB or code be auto-created for me.