Code First
-
R1911 wrote:
Article!
Some day. Want to help me write it?
Latest Article - A Concise Overview of Threads Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny Artificial intelligence is the only remedy for natural stupidity. - CDP1802
-
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
-
EF without "views" and "stored procedures" is like using C# without the .NET framework classes. EF "complements" the database engine; it doesn't "replace" it.
"(I) am amazed to see myself here rather than there ... now rather than then". ― Blaise Pascal
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.
-
Gerry Schmitz wrote:
DB first usually means there's a "DBA Administrator" in the house; which usually means 6 more months before you "get your database".
Very true. The DBA has to get everything right and that takes time. Here's the DBA schedule: 1. 5 months and 3 weeks and 4 days of Candy Crush "work". Must reach level 302!! 2. One day (Friday) of work to design the schema and create the tables on the server. :laugh: :laugh:
-
Entity Framework in agile environment - Design and Architecture Discussion Boards[^] Was reading this thread. Just want to really know, is there really someone who's using Code-first as the standard approach in their project? I've been trying to do this, but somehow the team environment/people rushes towards DB first. Even our boss is not so keen in getting to this :) Is this something we should definitely aspire to achieve or it's okay to continue with DB first approach?
Because I haven't spent the time to figure out how to code first write Clustered-Primary Key constraint, foreign key cascading rules, some foreign keys without requirement constraint, additional indexes that I can see a mile away. And that one bad time when I first started a code first project, then looked at the database and cried for all the 20+ character long guid names it attached to everything.
-
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.
-
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
-
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
-
R1911 wrote:
Article!
Some day. Want to help me write it?
Latest Article - A Concise Overview of Threads Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny Artificial intelligence is the only remedy for natural stupidity. - CDP1802
-
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, 2013well said
-
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.
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.
-
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 w
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.