|
Get the database right first, the rest is easy
We canβt stop here, this is bat country - Hunter S Thompson RIP
|
|
|
|
|
Frack no. It's the epitome of taking a very bad idea and following it ad absurdum.
|
|
|
|
|
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
|
|
|
|
|
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
|
|
|
|
|
I would not think about it. I would do it. We did it, it is a paradise.
|
|
|
|
|
|
My initial question is why?
What are you going to gain? Etc..
|
|
|
|
|
I like Break Before and After Code
|
|
|
|
|
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...
|
|
|
|