|
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.
|
|
|
|
|
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
|
|
|
|
|
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.
|
|
|
|
|
I do not like Code First.
Database First encourages one to carefully consider the modelling with considerations for normalization and database performance (which is often a bottleneck in systems). There are also many tools out there for modelling databases which makes visualizing and collaborating on the model easier. Finally, I just don't trust Code First to make the right decision for generating schemas for large or slightly complex models.
|
|
|
|
|
As with most such question, I think the best answer is 'it depends'.
I've found code first very useful when building out a smallish self-contained system (an android app with a .net / sql backend), which has about 15 tables and is unlikely to grow. The beauty has been that I can keep coding, adding things to the models as I prototype and get feedback, think of things I've forgotten, and don't have to muck around with sqlscripts. Simply add-migration from the package console and job done. However, once that system goes into production I will revert to a traditional approach.
On other bigger, more complex projects, where you have a logical schema with ~200 tables, there is no way I would do that code first.
|
|
|
|
|
|
Nine symbols for a seven letter word?
|
|
|
|
|
Nine, it actually is a Nine letter word
Something is wrong with me today.
1 --> Put a morning status (on one of my twitter handle) saying "Have a truthful Tuesday" (Even though it's Wednesday)
2 --> Put a photo of GARLIC BREAD I was eating a while ago calling it "GINGER BREAD"
3 --> And then this one
Gotta figure it out
|
|
|
|
|
Maybe there is some kind of miscounting infection spreading around this morning (see Griff's CCC below)
|
|
|
|
|
Quite possible
Yeah saw it. An infectious coincidence
|
|
|
|
|
You have a nice bouquet there...
Skipper: We'll fix it.
Alex: Fix it? How you gonna fix this?
Skipper: Grit, spit and a whole lotta duct tape.
|
|
|
|
|
Thanks Peter
I like flowers and trees. Though never liked studying em
|
|
|
|
|
You are begging for an answer?
Here is mine:
Botanical
|
|
|
|
|
Nah, was checking how the title of a product attracts customers
Plus I thought everyone in ignoring it, so...
You're up for tomorrow. Congo Jochen
|
|
|
|
|
I wasn't ignoring it, I just didn't have any idea!
Gawd, but I'm useless at these...
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
|
Invisible? It's obvious! (11)
[edit]Bugger - miscounted![/edit]
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
modified 10-Feb-16 4:38am.
|
|
|
|
|
I can see through that one!
Life is too shor
|
|
|
|
|
that's more than 10 characters
In Word you can only store 2 bytes. That is why I use Writer.
|
|
|
|
|
Yes it is 11... but I promise, the first time I counted it was 10!
Life is too shor
|
|
|
|
|
Bugger, bugger, bugger.
I need more caffeine...
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
Great minds count alike! I think you may understand that I feel slightly robbed of this one...
Life is too shor
|
|
|
|
|
I assumed from your first post that you'd got it, but didn't want to spoil the fun too soon.
And since you seemed to have got it, I also assumed I'd counted right...
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|