Partly; F# is a functional language, seemed to map to having everything in a function.
It's plain old procedural code.
In that case, I wrote a lot of those applications, in AMOS Basic. Somehow, that one seems to fit the previous description less than F#.
It became a mess quite quickly when your app grows larger. The best thing since sliced bread was the idea to group 'em. The idea that the local variables could be shared among that group was brilliant; took a lot of repeating parameters out of the procedures.
Lots of people still program in a procedural way in the new OO-environment, simply because it's easier to understand. And given recursion, you could still kill the stack.
Bastard Programmer from Hell
if you can't read my code, try converting it here[^]
I am hopeful that your question is confused rather than you and or whoever is providing this information to you.
Retrieving data from a database is a relatively expensive operation. Period. Doesn't matter why you do it. That however doesn't mean that you can retrieve it once only. The business needs drive in what way it can be retrieved.
You put database code in a database layer because that has multiple benefits. You don't put database code outside the database layer because doing that completely violates the point of having the database layer in the first place.
And notice that nothing in the above has anything to do with stateful or stateless.
For example, I once put an object reference inside a Hibernate DAO class and I was told that this was incorrect because DAO classes are not supposed to have state. State should be inside the 'service layer'.
As a general statement that is nonsense.
Implementing code for real businesses is not clean. You attempt to create well crafted code but only to the extent that it makes sense to meet the needs of the business.
Other than that I can only suppose that you did something really wrong in terms of service separation and database layer separation and that point was being emphasized.
The database layer should to database stuff. The service layer should do service layer stuff. Again normally, not exclusively.
And note that none of this has anything to to with the general topic of object creation. Nor with performance.
Create it once there and let the rest of the application access its instance later. Do not create this instance upon every call.
As stated generally nonsense.
It depends on what the object does. I don't need to retrieve the database connection string on every call. There is however no point in not creating a StringBuilder on every call.
Hello, CP, and good afternoon. I'm not sure if this is the correct forum but it seemed like the best fit. Please redirect if not.
Anyhow, I've been thinking a lot about this lately. Where I work, we have various partners who we work with for software solutions. Many of them create custom builds of their existing software to fit our needs. How would one go about creating customized builds of software to fit specific needs without modifying the entire solution? Is this implemented via source control, duplicating the project or what?
djj55: Nice but may have a permission problem
Pete O'Hanlon: He has my permission to run it.
This is the perfect place for this question, so don't worry about it.
To answer your question, for custom builds for clients, we use source control to manage this. Basically, we have a branching strategy where these clients are branched off our main development trunk. Appropriate changes from the trunk can be merged down to those branches as appropriate. The process is a lot more involved than this, but that's the basic level (because we have branches off branches, to deal with test phases, etc, and release branches - it all sounds horrendously complicated, but our CI procedures make it a complete breeze).
*pre-emptive celebratory nipple tassle jiggle* - Sean Ewington