|
That may be so, but these oldschool SPs designed to be used with DataSets, DataTables and DataRows do not have much in common with the Entity Framework.
I have lived with several Zen masters - all of them were cats.
His last invention was an evil Lasagna. It didn't kill anyone, and it actually tasted pretty good.
|
|
|
|
|
You're assuming every SP returns a result set; they don't.
And a "datatable row" is the equivalent of an entity.
One purpose of SP's is to execute logic on the DB server that has no business running on the client.
No SP's usually means: simplistic design; or poor design and poor performance.
"(I) am amazed to see myself here rather than there ... now rather than then".
― Blaise Pascal
|
|
|
|
|
Code first is fine for prototyping and knocking out quick things, but it's not suitable for production applications, IMEO.
|
|
|
|
|
Exactly. They don't tell you this in the documentation. 
|
|
|
|
|
By definition, a "production" system is past "code first" or "database first"; it's in maintenance mode; which will then probably involve both in one form or another depending on the "fixes" moving forward.
A database can have multiple data contexts.
A system can have multiple databases.
A system "enhancement" can involve adding a new database. Code first or database first?
"(I) am amazed to see myself here rather than there ... now rather than then".
― Blaise Pascal
|
|
|
|
|
What you described is a production environment, not a production system. By production system I meant an application that is intended to go live and be used in a serious business capacity.
|
|
|
|
|
No, I'm describing "systems"; "serious" ones: O&G production; Financials; MRP; etc.
And AP, AR, GL, FA ... all systems in the "bigger" Financials (system).
Nothing about "environment".
"(I) am amazed to see myself here rather than there ... now rather than then".
― Blaise Pascal
|
|
|
|
|
Quote: By definition, a "production" system is .. in maintenance mode
That reads to me that you were referring to the environment. If you actually meant "serious" apps, then what you said is that by definition serious apps are in maintenance mode and that makes no sense.
That's how I read it anyway.
|
|
|
|
|
In my world, there is "new development" and "maintenance".
(Proposed) "Systems" are analyzed (existing physical and logical); designed (logical and physical); developed; tested; integrated; documented; implemented (i.e. "put into production"); then, turned over for "support and maintenance" (by the group responsible for that area).
If you're a one man show, maybe you're always "in development" and don't ever get to "turn it over".
Actually, you better be clear knowing where "development" ends and "maintenance" begins:
That's what "service contracts" are for (and that's where your long term revenue OR expense comes from).
"(I) am amazed to see myself here rather than there ... now rather than then".
― Blaise Pascal
modified 12-Oct-18 11:38am.
|
|
|
|
|
Not quite what you are asking, but it made me think of one Norwegian author, Jens Bjørneboe:
He always started out the work on a new novel by deciding on the last word of the book. Everything in the novel should point towards the closing word.
The last word of his autobiography was to be "butterfly". He never got to complete it, though.
|
|
|
|
|
Just say no to Entity Framework.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
|
I guess you should mix it, as already commented, to push out prototypes and quick showcases it's fine to go code-first. For most other stuff i'd suggest DB first.
I for my self went up with all basic data i need for the application, built up the database and stuff and then coded. But for new small things that just need a new table or field i mostly design it in code first, show it, get the changes fixed and then put it in the DB before i code the final implementation.
Rules for the FOSW ![ ^]
if(!string.IsNullOrWhiteSpace(_signature))
{
MessageBox.Show("This is my signature: " + Environment.NewLine + _signature);
}
else
{
MessageBox.Show("404-Signature not found");
}
|
|
|
|
|
I usually work with dbs. So The db is already included in the virgin app/server code as a basic entity.
I also use the db for logging.
so its just natural.
It is just a part of the system. As per the remote hardware etc.
|
|
|
|
|
Code First is working fine for me in our airport management system.
Of course, I keep tight control over any changes to the model. 
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
I prefer using DB first... it's just easier for me to design the db and then use the scaffolding to make the EF (core) classes.
|
|
|
|
|
This is way too long but your question got me thinking and I just wrote it up.
It seems that CodeFirst was a way to get devs to :
"Do design in small chunks."
Some devs are not going to plan at all. They just start typing code.
A lot of those devs were very good at doing this and could really make things happen.
But others were terrible at it and created huge maintenance nightmares.
So a type of methodology arose out of that which said, "Hey let's make a process out of the idea of typing code. We need to provide a basic process."
Just Code It Up
In the beginning, many devs just typed code which was imperative in nature -- you tell the code what to do and it does it.
Along came OOP. But a lot of devs saw it and just said, "that's a lot of overhead, I can do it faster just by typing up some code" and continued just to "code up a solution".
OOP Wave
But OOP is about code organization and some people said, "Hey, you need to design things very well and think out everything so you can model the objects in the system and you should have everything planned out so you can go and create the system."
But it didn't catch on with a lot of devs because they knew that requirements change and you can't design any large system entirely before building because when you do you miss stuff.
But then many devs were like, "Well, we don't want to go back to just coding things up with no plan either."
Along Comes Agile
Model one domain object and get it working. Get the MVP (minimum viable product) so we can have a bit of design but actually start writing code and having things running very fast. This made the pantsers (coding by the seat of your pants) happy and made the strong OOP devs happier because at least there was some organization and process built into the system.
Everything else is just these two factions fighting it out:
1. Pure Agile - (design it on the fly)
2. Heavier process (design more up front / create large domain model ("all" objects in your system))
Reality: Stuck In The Middle
Real life is somewhere in between.
The Code First thing is a technological process that helps the first group (Pure Agile) to get to what they want with fewer technical barriers. Now they can model an object and it'll be serialized to the database with little work and each time they model a new object their domain model becomes more solid.
Of course Code First is also a process that is dev-centric where maybe you have devs that don't have as much experience with databases and they just want to get things serialized to db fast and easy.
Should you use Code First? Depends on your shop and how your projects are managed but everything is going to require some discipline.
For smaller projects or prototypes that you need to do fast, it probably is very nice.
But on large projects where you know there will be future maintenance you probably want to control every aspect of your system and may move away from Code First.
Summary
1. In general when someone says, DB design first, it is because they are thinking about more up front design (which is probably a very good thing).
2. In general when someone says Code First they are probably building a quick prototype or attempting to create the first revision of the design or they are implementing a stronger Agile approach with the discipline of designing the model along the way.
|
|
|
|
|
I don't see why your chosen project management methodology should drive your solution's technology decisions.
|
|
|
|
|
F-ES Sitecore wrote: I don't see why your chosen project management methodology should drive your solution's technology decisions.
It's a good point but also interesting that you see the items I talked about as a separate thing -- as Project Management.
Even if there is no official process, no methodology there is still something managing the project -- meaning some process that guides how pieces are completed.
It all melts together really.
Boundaries like PM, Dev, Test, etc are really false boundaries anyways, created to shove workers into roles that describe what they probably spend their time on.
|
|
|
|
|
raddevus wrote: there is still something managing the project -- meaning some process that guides how pieces are completed.
I disagree. Nowhere in the agile manifesto does it dictate what technology you can use, and the belief that agile means no planning\speccing and is about getting things developed "quick" are misunderstandings of agile, and one of its biggest enemies. There is no reason that code first is better for agile than database first, and if your project management is driving your technology then your project management is bad.
|
|
|
|
|
F-ES Sitecore wrote: Nowhere in the agile manifesto does it dictate what technology you can use,
I agree. I was trying to say that this is Microsoft's attempt to create a technology to help lead devs into this by providing a "design on the fly" type of thing. Design on the fly isn't quite right either and is a variable depending upon the team. Also thinking more about Agile Scrum here.
The point is, create one domain model into class model and Code-First it and you are on the steps toward iterative design.
F-ES Sitecore wrote: There is no reason that code first is better for agile than database first
Also agree. However, as I mentioned Code-First is a dev-first type of view - a technology that is an attempt to make it easier for devs to quickly design using Models and having them serialized to the database.
If the dev were to create the DB table first it could be seen as the model and design coming from that too. But devs are more code-centric and it is more common that when someone designs a database they do more than one table at a time -- just a convention.
F-ES Sitecore wrote: and if your project management is driving your technology then your project management is bad.
I think that this code-first idea has little to do with project management because it is coming from the devs viewpoint. This is probably used more in cases where there is no project management.
Which goes back to my original post that I am saying that this whole Code-First thing was a way to lure devs into at least creating models first (very minimal design) and allow them to design one model at a time (iteratively) and is generally so loose that it would be mostly for prototyping or first run design.
Also throughout all this I'm not saying that the Agile Principles mean that there is no design. I really like the original Agile Principles[^]. I'm saying that they do say, "Working software is the primary measure of progress." so code-first is an attempt (however good or terrible it may be) to help devs design iteratively to get to running code (serialized to db) as quickly as possible.
Also, of course, I am saying that all design is not done up front as another principle states, "Deliver working software frequently, from a
couple of weeks to a couple of months, with a
preference to the shorter timescale. "
Good discussion.
|
|
|
|
|
Sometimes, designing on the fly is the only option.
I design the hardware, firmware and software. For systems.
A lot of these are multilevel in HW & FW.
It is called research and development.
Therefore I always include a DB in the design.
If not used take it out. Which is easier to do than put it in latter as per encryption.
Put encryption as standard. If not required, it does not matter. putting it in later may be annoying.
Anyway.
|
|
|
|
|
Regrettably, "agile", as used today, is almost devoid of meaning.
Its a shame the intent of the original agile manifesto is largely forgotten. It was a simple statement of principles that stressed flexibility not only in design, but also in process.
The primary issue I have with current claimants of agility is the rigidity of process. Any objective observation of a flaw results in a reflexive "you're doing it wrong". The mere possibility of any flaw in the process is unacceptable. This is simply dogma and IMHO the exact opposite of the agile manifesto's goal.
Oh well...the folks who pay the bills get to call the shots...however counter-productive they may be. I'll keep cashing the checks and wait for this nonsense to pass. Hopefully, it will, before I do 
|
|
|
|
|
|
Oh thanks for the wonderful reply. 
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
