|
Tim Carmichael wrote: In a .NET application, what process should be used to obtain a series of Setting values? A procedure? A function? Local variables? Global variables? Pass a structure?
That's an open ended question. Sounds like marketing trying to describe tech, or a way to dance around asking a real programming question. Ether way, what you're talking about is application architecture and design. Crack open a book man, that's what we did.
Jeremy Falcon
|
|
|
|
|
Actually I don't understand your question, but I will explain the usage of these, procedure, I have used them in SQL but never in .NET so no wrong information,
A function is something that you write to recall the very same set of code block. For example, you write a code that gets repeated at many locations in your software, so you create a function, and place that code block in it and recall it each time you want to use it. Like this
private void SomeFunction () {
}
Local variables are the variables present or defined inside any function block, like main function or any custom function whereare Global functions are present anywhere inside the class, that are accessible in every code block on that class file.
A Structure is opposite of Class, similar is behaviour, in struct, you send the object itself inside the function, whereas in the class, you just send the copy of it. In struct you actually pass the reference of the object.
You can use them in your coding to make your software efficient. Sorry for not-answering your question because I don't understand it.
Favourite line: Throw me to them wolves and close the gate up. I am afraid of what will happen to them wolves - Eminem
~! Firewall !~
|
|
|
|
|
|
By "series", do you mean a time series (i.e. values that can change over time) or a group (i.e. a batch) of setting values?
/ravi
|
|
|
|
|
Tim Carmichael wrote: should be used
Whatever you are most comfortable with. Don't just follow the pack.
Actually, it's not a very clear question. Where do the "Settings" come from?
|
|
|
|
|
For me a pair of Levi's and a T-shirt? 
Have you ever just looked at someone and knew the wheel was turning but the hamster was dead?
Trying to understand the behavior of some people is like trying to smell the color 9.
|
|
|
|
|
|
Holy crap on a cracker... ask a simple question...
I know what a function is and what a procedure is and how they are used.
I started with a procedure: GetSettings and passed in a number of local variables.
But, then I thought, a procedure shouldn't be returning values, that is what a function does.
However, there is more than one value to return (currently 6), so I decided to use a stucture and have the function return a single structure with values in each element.
The series of data is: source directory for file to be processed, from e-mail address, to e-mail address, SMTP server, report type (row or column based), single e-mail or an e-mail per file processed.
Now, having been on here for some time, I have seen flame wars on style: what should a procedure to, what should a function do, blah, blah, blah....
So, simple question of style and maintainability...
|
|
|
|
|
OK, seems pretty straightforward then.
SettingsSpec settingsSpec = new SettingsSpec { Var1=..., Var2=..., etc };
Settings s = SettingsManager.Instance.GetSettings(settingsSpec);
If you prefer to go the dependency injection way, do:
SettingsSpec settingsSpec = new SettingsSpec { Var1=..., Var2=..., etc };
SettingsManager settingsMgr = new SettingsManager(settingsSpec);
Settings s = settingsManager.GetSettings();
/ravi
|
|
|
|
|
(I know C++)
Always limit the number of parameters, especially returned parameters (references in C++); Use a struct to hold the settings.
It will also be easier to maintain if you decide to add or remove data to the parameters and/or need to do some processing on the data in the struct (in C++ one would make it a class (*))
If necessary, return a bool if the function can fail and you need to know about it.
(*) even if there are no significant difference between a class and a struct
I'd rather be phishing!
|
|
|
|
|
Thank you... that was my eventual thought, but it took me a while to get there.
|
|
|
|
|
Using a struct seems a good way to go.
Another option is to use an XML string, which is a bit more overhead but could be handy if you need to write to and retrieve from disk/database. But otherwise the struct is probably better.
|
|
|
|
|
Tim Carmichael wrote: Holy crap on a cracker... ask a simple question...
Your question wasn't all that thought out though. It was basically asking something like "what does green look like?" So, holy crap on a cracker another post with some vague nonsense!! At least this post was better.
Jeremy Falcon
|
|
|
|
|
Tim Carmichael wrote: ask a simple question...
that wasn't obvious from your wording as you can see by the responses!
I'd definitely say that using a struct (or a class) is the way to go, assuming this us used something along the lines of
{
var myNewStruct = getSettings(someIdentifyingParameters);
SendEmail(myNewStruct)
}
But if the contents of the struct are relevant to the context of the class, then I'd have them defined as a private field
PooperPig - Coming Soon
|
|
|
|
|
Tim Carmichael wrote: So, simple question of style and maintainability...
Yes, but maintained by who?
If you're working in a code base maintained by others, follow the pattern that they set and do what they do. Not because it's stylistically right, but more because they'll understand what you've done quicker with less chance of understanding it wrong.
If you're writing something that only you will maintain, or is throwaway, then do what seems right, or whichever way you want to practice.
We can program with only 1's, but if all you've got are zeros, you've got nothing.
|
|
|
|
|
You know this is a programming question, right? and it is not a matter of style but rather doing things the correct way or the wrong way, IMHO.
Settings could be put in a app.config or web.config file and recalled in your application using the .net library/class ConfigurationManager, I believe.
|
|
|
|
|
I agree with this, this is the way I would go. You can create settings sections as well and put them in unique .config files. By doing it this way, all the heavy lifting is done for you by the ConfigurationManager class.
This article makes a fair stab at describing how to use it (it's a lot simpler in practice once you get your head around it)..
Custom Configuration Sections for Lazy Coders[^]
How do you know so much about swallows? Well, you have to know these things when you're a king, you know.
modified 31-Aug-21 21:01pm.
|
|
|
|
|
Take that hat off for a start, Dahling. It doesn't fit you at all.
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
On Thursdays I dress smartly to increase the SNR with Dress Down Friday.
Today I wore a new shirt made for me in New York(excellent value!), my grey worsted suit and a Bowler; also I carried my city umbrella(it might rain) and wore a fine tie by Hawes & Curtis in Gloucester.
And now if you don't mind, I have an appointment for lunch. 
|
|
|
|
|
Just do what a tool such as Resharper or CodeRush suggests
Then you can spend your time thinking about more important things
|
|
|
|
|
I manage my own settings (i.e. "config file") using environment variables to determine where to store them (e.g. "Program Data"; "User Data"; "Documents and Settings"; whatever ... depends on the OS).
You can use the .NET "built-in" functions for managing "user.config", but .NET tends to create multiple folders, and copies of your config.file, when you start "versioning" your program (can get really confusing / messy ... IMO).
As for "consumers" of your settings ... use "dependency injection".
(In some cases, settings could be stored on a web server and accessed via a web service by the clients when you're dealing with an app that is "distributed"; e.g. kiosks).
Since we're talking .NET ... manage you settings with a class; serialize and deserialize them using XML; and retrieve them initially at app start-up.
(A "procedure" is just a "function" that "returns" void ... IMO).
modified 21-Aug-14 17:49pm.
|
|
|
|
|
|
Alas, gender and sexuality are two completely separate things -- they'll need to add more options if they wish to combine both into one setting. 
|
|
|
|
|
My sexual preference enum has but three options:
public enum SexualPreference
{
Males,
Females,
YesPleaseOhGodYesPleaseAnythingWithAPulse,
}
You looking for sympathy?
You'll find it in the dictionary, between sympathomimetic and sympatric
(Page 1788, if it helps)
|
|
|
|
|
OriginalGriff wrote: My sexual preference enum has but three options:
Women
More Women
Bacon
??
Jeremy Falcon
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
