|
GKP1992 wrote: Spilled a cup of coffee on my keyboard and me.
I am a true professional now.
If it was a McDonalds coffee from New Mexico you could sue and claim it was just too hot.
Michael Martin
Australia
"I controlled my laughter and simple said "No,I am very busy,so I can't write any code for you". The moment they heard this all the smiling face turned into a sad looking face and one of them farted. So I had to leave the place as soon as possible."
- Mr.Prakash One Fine Saturday. 24/04/2004
|
|
|
|
|
Sadly, I served it myself.
|
|
|
|
|
So sue yourself.
A competent lawyer can find a way to work a profit out of it.
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!
|
|
|
|
|
|
See!
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!
|
|
|
|
|
I'm absolutely sure the lawyer would profit from it, not so sure that GKP1992 would come out well though.
"If you don't fail at least 90 percent of the time, you're not aiming high enough."
Alan Kay.
|
|
|
|
|
Did I say GKP1992 would do well?
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!
|
|
|
|
|
I used to drink beet juice when was younger - the only person with a purplish C64 me think
"The only place where Success comes before Work is in the dictionary." Vidal Sassoon, 1928 - 2012
|
|
|
|
|
I noticed that you avoided mentioning whether this was a working purplish C64 or not.
|
|
|
|
|
Welcome to the true achievers' club!
- I would love to change the world, but they won’t give me the source code.
|
|
|
|
|
1. generate DAL, admin UI and DB from an XML schema source?
2. generate XML schema, admin UI, and DAL from a DB source?
3. ignore XML and simply generate the admin UI and DAL from a DB?
4. I hate code generation. Let me do it the hard way.
5. Everything about this question sounds like my own personal hell.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
5
A DAL cannot be generated.
A UI cannot be generated.
XML schema cannot be generated. (Or at least it would need to be tweaked afterward.)
I do generate some small pieces of code (enumerations) from DB.
Nothing significant can be done via automated tools.
|
|
|
|
|
hmmm. i must have generated some imaginary dals in my time. same with the schemas and the admin UIs.
(although UIs usually require tweaking, even CRUDdy admin stuff)
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
You must have. It's probably all worthless.
|
|
|
|
|
they made some people a lot of money, so I guess so.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
codewitch honey crisis wrote: i must have generated some imaginary dals in my time The word you're thinking of is "conjuring".
Us non-magic users can't conjure up code especially if no dark arts are involved.
BURN THE WITCH! (I finally found my torch and pitchfork!)
|
|
|
|
|
bwahahahaha
i'll get you my pretty. and your little dog too.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
PIEBALDconsult wrote: A DAL cannot be generated. Amazing as I have been doing just that for 30+ years, by the great Ghu I must rethink my entire development strategy as I generate the API code, the client DAL, the controllers and some of the UI controls based on the database structure.
Never underestimate the power of human stupidity -
RAH
I'm old. I know stuff - JSOP
|
|
|
|
|
was my thought too.
like, there are tools out there already, even if i hadn't written my own.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
5.
«Where is the Life we have lost in living? Where is the wisdom we have lost in knowledge? Where is the knowledge we have lost in information?» T. S. Elliot
|
|
|
|
|
I hate XML.
Does that help?
|
|
|
|
|
i hate XML as well, but it *does* have an annotatable schema and that makes it useful as hell for stuff like this
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
I recently generated a service based on a WSDL (which is XML).
I had to do the implementation myself and heavily tweaked the generated code and it was WCF which I generally hate so it was all personal hell, but I'm using generated code now.
I generate the database using EF Code First (so that's not XML).
I've generated UI's from the DB in the past, which never really works out the way you want to.
Generally, I dislike working with XML, so mostly 4 and 5.
|
|
|
|
|
Personally, I'm a fan of generating code.
Think about a set of stored procs in a database that I want an application to be able to call. I have three alternatives:
1. I can write a common CallProc method, that calls any proc with an array of arguments
2. I can generate a single method for each one using the database metadata including typed arguments.
3. I can hand write number 2.
Clearly, option 3 is inefficient, from a developers time, the riskiest for defects.
Option 2 is the most extensible - no additional work is required to add a new proc to the system.
Option 1 presents the programmer calling procs with the nicest API. It is also likely to be the most performant (any performance tweaks coded in the others can be included in the generation templates)
Option 1 will be the largest code footprint, and an extra code generation step is required to generate the code, so ease of use depends on the level of support for this in the development environment
Hence I vote for 1.
It's almost a clarification to the DRY principle - Don't repeat yourself, have a code generator repeat yourself.
However for generation to be viable, the generated code must never be edited. This is why partial classes in c# and similar are almost essential.
The second part of the question, is if generation is to be used, what should the model be: DB source or code or external model.
Here we stumble into the classic 'impedance mismatch', The ideal database model does not correlate with the ideal code class structure. This mismatch is why people will hate code generation. Too many ORMs are simply mapping 1 table to 1 class. When generated from the code, the database structure is often sub-optimal and likewise the other way around.
There are parts of a code model difficult to express in a database model.
Hence I prefer external models, particularly in web development. I can define a data model, an api (with validation) and generate the database schema, the javascript/typescript side of the code, the server side of the code (in multiple languages).
What you end up with is essentially an independent development environment, so it can be taken too far.
I haven't done much with generating UI code yet - the partial class constraint tends to keep me from exploring this in detail..
|
|
|
|
|
you ripped this entire comment straight from my head. How?
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|