|
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
|
|
|
|
|
Thanks for your feedback. I appreciate it. 
|
|
|
|
|
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(); }
|
|
|
|
|
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.
|
|
|
|
|
that will be 5 concurrent users before the crash.
it ain’t broke, it doesn’t have enough features yet.
modified 20-Oct-19 21:02pm.
|
|
|
|
|
|
Interesting.
Unfortunately, the world I live in revolves around "what can you give me in a certain time frame?". This does not lend itself well to theoretical software development, or hobby craft, where it may or may not work.
Now, after a few years, and it has moved from philosophy into mainstream practice, then I would consider adopting. --> You used the phrase "may free us", in your linked page article, which has a certain level of uncertainty to me, hence the tone of my reply. 
|
|
|
|
|
Some industries (financial services, mobile phone billing etc.) are already using this model.
Unfortunately the code we/they use is very proprietary and this kind of thing is not used in college courses (yet).
Commercial offerings do exist - in particular Event Store[^]
|
|
|
|
|
I'm working on a project right now and we used Code First.
There's some nice stuff about it if you keep your database simple, but what database ever ends up being simple, right? Stuff like Migrations can make changes very easy to implement but others a real pain in the ass.
If you've got a very small team, like under 5 people, Migrations can be easy to manage. If not, it can be a huge pain. It's probably best to keep the Migrations limited to just a few people on the team until the database is fleshed out. Multiple people putting in migrations on the same table at the same time can make your life miserable. We ran into a couple of problems like this and I'm one of two people working on this project. If you're going to have multiple people doing Migrations coordination of those changes is paramount. I can't stress that enough. If you want to avoid problems, you have to make sure no two people are making changes to the same table at the same time.
You REALLY have to understand your data and how relationships work before you even think of starting with Code First. Code First isn't the best when determining how it's going to setup a relationship and you really have to know your DB stuff to make sure it's getting it correct.
When Code First doesn't get a relationship correct or exactly the way you want it there is a rather steep learning curve to the syntax to configure it correctly and it only gets steeper if you don't know enough of the detail of how the database side works and the terminology involved.
Would I use Code First again? Sure, but not for large projects. I'd keep it to smaller ones only.
|
|
|
|
|
|
I like it. Different from DB first, but the automatic db intialization is neat.
|
|
|
|
|
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.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
