|
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
|
|
|
|
|
that's precisely what I used to do when I worked for a little company called Acrosonic.
I generated everything from a schema, and used schema annotations, like ui:cell="top-left", ui:type="checkbox", db:column="name", that kind of thing.
it works pretty well although the schema ends up looking like a microsoft xdoc when you're done with it.
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.
|
|
|
|
|
If you generate a data-access layer, it will screw it up (no maybes).
If you even dream about generating a UI, you should not be allowed within a thousand miles of UI design*.
If you generate an XML schema, you'll probably end up probably wasting hours and hours of your time fixing it.
WTF do you want to generate these things for? How lazy are you?
It's part of the job. Just sit your arse down in your seat and get on with it.
* Or my "ready-to-strangle-you" hands.
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
a) i've generated dals just fine. some are still in use in production last i checked despite me being out of the field for some years.
b) i wasn't talking about generating a general UI, but an admin UI, where often records are edited with CRUD style access
c) i agree with this, which is why i tend to source my generation from an annotated xml schema.
d) to save time and money. lazy enough to not write code the computer can write for me.
e) the first thing they teach you at microsoft is to work smarter, not harder, and that's where i got my start professionally.
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: the first thing they teach you at microsoft is to work smarter, not harder
This has nothing to do with "working harder"; it's about attention to detail.
"Working smarter" means ensuring that none of your time is wasted. Not sitting your arse in your chair and making sure that every detail of what you do is accurate, correct, and functional in all situations means that your time -- and the time of others -- is wasted. Doing otherwise ain't smart, so getcher arse in the chair and go through everything 99 times, to make sure that every tiny detail of one thing is perfect, before moving on to the next.
If you call that "working hard", rather than "working smart", then we're in disagreement. TBH, I just call it "working", because it's the only (and most productive) way to work.
Of course, when all a company does is make new icons and smileys, they might have a different perspective on that.
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
generation helps with that. the more code you write by hand the more bugs you can introduce.
it's better to use machine generated code when that code is suitable for the task. it costs less, and code coverage isn't as mission critical in tests (which in the real world in most shops never approach full coverage if they even track testing at all)
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: it's better to use machine generated code when that code is suitable for the task.
That could be said, but, for me, every generated statement has to be checked by developers with the same diligence as every other statement in the program.
It don't matter none whut wrote it, it has to be checked with pure human bum-in-seat diligence.
I've rarely found it to save time, in shops that demand real precision.
Cause confusion, sure; save time, no.
We're still not at the point, in almost everything, were absolute precision can be generated, and even generating "little and obvious" stuff leads to lots of human double and triple checking.
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
i check the generation. it gets checked once. if you're checking generated code more than cursorily after that you're duplicating effort, and in this case that's a huge time waster.
i've been coding for about 32 years, professionally i did for about 20. In that time I've generated a lot of code.
In fact, I don't think I've ever worked on a 3-tier app I didn't have control over that didn't use at least 15% of the middleware code being generated, if not more. At companies like Acrosonic it was a lot more, because we didn't have very many devs, and we had a lot of diverse clients with diverse needs.
If you want to build "vertical applications" for small businesses for example, generated code is your way to do so profitably.
And if you want to architect enterprise apps, generated code is often going to be a part of it, at least if you're dealing with anything redundant.
Edit: I should add that this is going to probably be an intractable philosophical difference between you and I, and I am okay to agree to disagree.
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: Edit: I should add that this is going to probably be an intractable philosophical difference between you and I, and I am okay to agree to disagree.
Agreed.
Or do I mean "disagreed"?
Damn! My Response Generator can't handle this!
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
you've been replying to mine the entire time 
welcome to my AliceBot, codeproject edition.
just kidding
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.
|
|
|
|
|
Err368
alicebot implied
discontinue
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
I'd use typedef if C# had one as powerful as C++'s. Using just doesn't cut it.
in the meantime it's VAR ALL DAY LONG.
Haters gonna hate.
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.
|
|
|
|
|
Even VS 2019 asks to create a strongly type variable rather than a var in a lot of cases. So yes, take your VAR and shove... (SMACK)
Never underestimate the power of human stupidity -
RAH
I'm old. I know stuff - JSOP
|
|
|
|
|
i will take hostages if i must in order to avoid typing long as days generic and tuple declarations.
you have my list of demands. it is simply. I require typedef.
otherwise, VAR VAR VAR!!! =D
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.
|
|
|
|
|
and the minute i take coding advice from Microsoft's Clippy, just go ahead and shoot me in the face. With a .45. I don't deserve an open casket.
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.
|
|
|
|
|
Ah Clippy, despised even more than VB. I consider siri, cortana and all their ilk the bastard children of Clippy.
Never underestimate the power of human stupidity -
RAH
I'm old. I know stuff - JSOP
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
