|
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. 
|
|
|
|
|
DB first usually means there's a "DBA Administrator" in the house; which usually means 6 more months before you "get your database".
"(I) am amazed to see myself here rather than there ... now rather than then".
― Blaise Pascal
|
|
|
|
|
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.
|
|
|
|
|
And at that point, Applications Development needs to add another 6 months because "5th normal form" was not what they had in mind.
"(I) am amazed to see myself here rather than there ... now rather than then".
― Blaise Pascal
|
|
|
|
|
It depends. You really have to think ahead to where your performance bottlenecks will be.
If the project's end program will be accessing a lot of information randomly from the database then the design should be DB first. The reason is your database is where your information bottlenecks will be since you can only query from disk so fast. Network doesn't play much into this as network speeds are mostly constant with little gains to be had.
If the project isn't making calls to the database constantly, then code-first is acceptable since your bottleneck will most likely be in how the user interacts with the program.
if (Object.DividedByZero == true) { Universe.Implode(); }
|
|
|
|
|
We divide ours out, schema changes are in one story and then the ETL process is another. Schema stories are played first so that the guy doing the ETL has somewhere to stick the new data.
|
|
|
|
|
R1911 wrote: Is this something we should definitely aspire to achieve
No.
or it's okay to continue with DB first approach?
Yes.
Code often enough wants to see the data in a different way than is best for DB performance and normalization. I prefer to implement the DB first and generate the model (classes) from the DB (as partial classes so I can, if necessary, extend them with helpful properties, and either create views in the DB or views in the code from the model.
Furthermore, by specifying my DB models myself and using FluentMigrator and a custom tool that I wrote, I can also specify attributes on the fields that drive the UI behavior, like:
{Name: 'IsManager', Type: 'bool', IsDisplayField: true, DisplayName: 'Is Manager?' },
Add comments to the metadata, like:
{Name: 'IsCommunityStaff', Type: 'bool', Comment: 'For community cash drawer support.'},
Specify interfaces that the model should implement, like:
{Name: 'Fingerprint', Implements: 'IFingerprint',
custom formatting (I'm using DevExpress for the UI controls) like:
{Name: 'TaxRate', Type: 'decimal', ActualType: 'Number4', IsDisplayField: true, DisplayName: 'Tax Rate as %', Format: '###0.0000'},
drive lookups implemented as dropdowns like:
{Name: 'DisputeTypeId', Type: 'int', DisplayName: 'Type', FK: 'DisputeType.Id', IsDisplayField: true, LookupModel: 'DisputeType', LookupField: 'Name' },
and specify initial load of data when creating the DB from scratch, like:
{ Name: 'DisputeType', IsLookup: true, Fields:
[
{Name: 'Id', IsPK: true, Type: 'int', IsIdentity: true },
{Name: 'Code', Type: 'int' },
{Name: 'Name', Type: 'string', IsDisplayField: true },
{Name: 'Description', Type: 'string', Nullable: true, IsDisplayField: true },
],
InitialLoad:
[
{Code: 0, Name: 'Shopper', Description: 'Did not receive products/services, dissatisfied, not refunded, etc.'},
{Code: 1, Name: 'Process Error', Description: 'Charged twice, charged incorrect amount.'},
{Code: 2, Name: 'Fraud', Description: 'Stolen card.'},
{Code: 3, Name: 'Friendly Fraud', Description: 'Customer claims valid purchase was fraudulent, etc.'},
{Code: 4, Name: 'Other'},
]
},
and implement custom code generation, for example when a table has a a field called "Archived":
{Name: 'Archived', Type: 'bool'},
which generates the code for me to archive the record if it's referenced by other tables when the record is deleted:
public void OnDeleted(RowDeletedEventArgs args)
{
if (((IReferenced)args.Entity).IsReferenced())
{
ArchiveController.Archive<TaxCode>(args.Entity);
args.Handled = true;
}
}
(Though I'm thinking of changing that to use an IsArchivable attribute on the table rather than rely on a specific field name.)
The end result is that the model metadata specifies:
- the DB
- additional characteristics of the model class, like interfaces
- initial data load
- UI behavior
- generates code for custom behaviors like archiving
- additional documentation as comments useful for the developer
and as mentioned, it generates all the code needed to work with FluentMigrator.
I haven't looked at EF in ages, but I doubt it can do all of this stuff, which reduces my model development and maintenance time by easily 90%. I've done demos with my client where he'll say, oh, I'd like this field formatted as blah, or I'd like an additional field for this option, and I'll edit the JSON metadata, generate the migration code, run it, and the app reflects the changes, without touching a line of code.
So, you might say, I adhere to a "Code Last" principle.
[edit]Oh, an from the JSON metadata I generate a "report" on the schema -- it's relationships, tables that are just lookups, tables that support archiving, dependencies on archivable tables, etc., which is useful to review to make sure my model is designed correctly.[/edit]
[edit2]And did I mention that it's WinForm / Web agnostic, particularly when using a web UI like jQWidgets - JavaScript UI Widgets framework which requires only a little bit of client-side Javascript to manipulate it for the desired effects based on the JSON schema.
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
modified 11-Oct-18 9:57am.
|
|
|
|
|
I'm curious, do many of your clients development teams adopt this methodology, the level of discipline would need to be quite high. I have fiddled with a number of meta data structures over the years but could never convince a team of junior developers to adopt and adhere to the structures.
I ended up with a convention based environment where the first field is a primary key, identity field with the same name as the table +ID. Views with the same name as the table prefixed with vw. All this allows the custom app "ClassBuilder" to generate the procs, DAL and partial UI files from the table/view.
ClassBuilder, which I filched in the early 90's, is in use in a number of organisations where I have contracted over the years, primarily because it is relatively simple.
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
Mycroft Holmes wrote: do many of your clients development teams adopt this methodology, the level of discipline would need to be quite high.
Good question. Given that I am the development team for several of my clients, I can customize my toolset as I choose.
Mycroft Holmes wrote: but could never convince a team of junior developers to adopt and adhere to the structures.
Conversely, when I've worked with teams, particularly with junior developers, I learned a lesson a long time ago that you don't rely on them to use and maintain the metadata -- they're just not used to thinking in those terms. But what I found did work, and worked quite well, is to provide a UI designer. Junior devs (and even senior devs) feel more comfortable with a designer, rather than mucking around in the XML, JSON, or whatever. And it also gives management the impression that you're using a professional tool, not some half baked roll-your-own implementation (which is what it is under the hood, hahaha.)
At one point (2005 or so), I had co-opted the WinForm designer, added a (quite sophisticated) schema designer, a custom scripting language, and embedded the DevExpress report designer, all UI-based. The management and the devs loved it. A lot of work to hide the fact that all it did was generate XML, but it was worth 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
|
|
|
|
|
Article!  thanks!
|
|
|
|
|
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
|
|
|
|
|
Sure definitely. Please let me know , how do we start & proceed.  Thank you!
|
|
|
|
|
The only time I've have to deal with "Code First" was with a lead developer who was scared of SQL due to tooo many run-ins with Little Bobby.
Took me almost a year to clean up an database created by LINQtoSQL (pre EF)
Director of Transmogrification Services
Shinobi of Query Language
Master of Yoda Conditional
|
|
|
|
|
There's a lot of waffle in the responses but the truth is as it is for most things... It depends on what you're developing. Some people have alluded to this.
I have worked on projects that have used code first effectively. No performance bottlenecks, easy deployments, very neat code. Easy to follow and all in one place. If you have a fairly simple schema to create, code first is not going to be a problem. If you have a more complex schema, then you may have to evaluate it a bit more.
I have worked on projects that code the DB first. This gives you the most control and is the more consisitent approach when writing stored procedures, triggers and other object types. If using Visual Studio (assuming as you're using EF) and if you're also using SQL Server then Visual Studio DB projects are great for modelling databases and doing quick and easy deployments.
ORMs are great but use with a little caution as you may introduce unnecessary overheads.
In summary, to answer your question more directly, yes code first is used for real applicstions/projects. On the question of whether to aspire to it, I do not believe it should be considered a standard or any sort of evolution of development - you would use it based on the merits for your application.
|
|
|
|
|
We always do code first, but we also follow a very strict and sane DB design principle.
"Everything is flat by design and we optimize for lowest complexity."
Juniors that optimize for "This is going to be faster and/or more efficient" are getting stabbed with a knife by me personally.
People prefer DB first, because they like to decide what the data should look like.. which is also fundamentally wrong.
Data already has a defined structure when it gets into your system, and has a defined structure when it comes out.
All you need to do is flatten it in a safe way, so you can persistently store it, when it's in between those 2 states.
The worst of the bunch are Enterprise folks that go on and on about Business Objects or Domain Objects.
They're willfully ignoring their core business (= selling a product or service) in favor of making arbitrary decisions about things they've invented themselves.
We call that "having a god complex", because it's fun playing god and creating stuff that people will build for you.
I totally get that. But they should do that in Civ5 or something, not at work.
|
|
|
|
|
If starting from scratch, the advantage of "code first" is that the database that is generated "works" with EF.
On the other hand, database first assumes you have the smarts to now "confgure" EF to "consume" whatever convoluted schema someone managed to create using "SQL".
Now try and keep the 2 in sync.
The skill is in knowing when to use which; or both; and transitioning from one to the other.
"(I) am amazed to see myself here rather than there ... now rather than then".
― Blaise Pascal
|
|
|
|
|
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.
|
|
|
|
|
Them hamsters eat your cable? I saw you!
"If we don't change direction, we'll end up where we're going"
modified 11-Oct-18 5:45am.
|
|
|
|
|
For some reason - probably a CTKI error - the Lounge wasn't showing me updates, so I missed your CCC by over an hour!
As soon as I posted, however ...
Sent from my Amstrad PC 1640
Never throw anything away, Griff
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
Hi All,
In response to my company getting all worked up over security, I took the plunge and ordered comedy ID Lanyards (I was drunk when I pushed the button). Now I have a pile of funny lanyards, which at least one CP member has contacted me about so being a private member, not running a business can I post details of how to get these things from me via eBay with enraging one the Hamsters  .
|
|
|
|
|
Did your company pay for these lanyards or did you pay for these with your own money? If the company paid for them, then you can't sell them without the company's consent; seen a few get fired for this over the years (old printers, toner cartridges, etc.)
|
|
|
|
|
I paid (drunkenly) for them, I have given up trying to claim expenses over the year's.
|
|
|
|
|
What’s it going to be then, eh? A sundial job colour? (1, 9, 6)
"If we don't change direction, we'll end up where we're going"
modified 11-Oct-18 6:24am.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
