|
|
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.
|
|
|
|
|
I tend to generate stuff out of the C# domain model - using code attributes to control the generation (including the "don't even try to generate this, I'll write it myself" settings of course). Originally I did it with reflection on the compiled domain model, but the last time I used Roslyn - which was kind of OK. Though I had to generate more than the DAL/UI (converters for a versioned API, gRPC layers to transition between processes and other enterpricy stuff).
|
|
|
|
|
I wrote my own DAL about twenty years ago and I still use it, occassionaly I've added / changed things but it does for me. I absolutely loathe EF and any ORM
We can’t stop here, this is bat country - Hunter S Thompson RIP
|
|
|
|
|
codewitch honey crisis wrote: 1. generate DAL, admin UI and DB from an XML schema source?
That one, except at this point I'd probably use JSON. The problem is, whatever the schema is in, there needs to be a good way to detect changes and migrate those changes to the DB.
#1 has the advantage that additional metadata can be put into it that isn't necessarily captured by the pure DB schema. The problem though is that it can quickly start to look like a UI view definition, which can vary while the schema stays constant. So that trap needs to be avoided, though I don't see any reason why the schema metadata can't define certain defaults, like the default control type to render on the UI.
Also, the DAL is often overkill -- most of the time, you don't need a DAL to serialize the records into class instances, only to map the class properties to UI elements (whether WinForm or web UI's). There's so much automation that can be done (and that I have done) to eliminate the "class" middleman and determine the DB transaction from the table changes directly.
Marc
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
