Is my parameters model good?
I develop next application parameters storing paradigm:
There is enum for each parameter roles
enum ParameterRole
{
FileName,
FileDir
}
Parameters are contained in special container as object
class ParamContainer : Dictionary(ParameterRole, object) {
public new object this[ParameterRole role]
{
get
{
if (base.ContainsKey(role))
{
return base[role];
}
else
{
return null;
}
}
set
{
if (base.ContainsKey(role))
{
base[role] = value;
}
else
{
base.Add(role, value);
}
}
}
}
It's private member of AppSettings class
class AppSettings {
ParamContainer container = new ParamContainer();
public string FileName
{
get
{
return container[ParemeterRole.FileName] as string;
}
set
{
container[ParemeterRole.FileName] = value;
}
}
}
and for each settings there is a corresponding property, but it works not with a local variable, but adds/gets a value from the container.
What benefits?
You can work with parameters separately as named property, so as list (container.Keys, container.Values) - it's useful for SQL queries and XML based business logic.
What deficiencies?
Parameter values are stored as object and it uses more memory as it could, I guess, if was stored as it's corresponding types.
What do you think about it? It's very interesting and important for me.
Is it rubbish or could be useful?
c#
asked Dec 27 '08 at 10:30
abatishchev
257111
migrated from stackoverflow.com May 1 '12 at 2:09
This question came from our site for professional and enthusiast programmers.
add a comment |
I develop next application parameters storing paradigm:
There is enum for each parameter roles
enum ParameterRole
{
FileName,
FileDir
}
Parameters are contained in special container as object
class ParamContainer : Dictionary(ParameterRole, object) {
public new object this[ParameterRole role]
{
get
{
if (base.ContainsKey(role))
{
return base[role];
}
else
{
return null;
}
}
set
{
if (base.ContainsKey(role))
{
base[role] = value;
}
else
{
base.Add(role, value);
}
}
}
}
It's private member of AppSettings class
class AppSettings {
ParamContainer container = new ParamContainer();
public string FileName
{
get
{
return container[ParemeterRole.FileName] as string;
}
set
{
container[ParemeterRole.FileName] = value;
}
}
}
and for each settings there is a corresponding property, but it works not with a local variable, but adds/gets a value from the container.
What benefits?
You can work with parameters separately as named property, so as list (container.Keys, container.Values) - it's useful for SQL queries and XML based business logic.
What deficiencies?
Parameter values are stored as object and it uses more memory as it could, I guess, if was stored as it's corresponding types.
What do you think about it? It's very interesting and important for me.
Is it rubbish or could be useful?
c#
asked Dec 27 '08 at 10:30
abatishchev
257111
migrated from stackoverflow.com May 1 '12 at 2:09
This question came from our site for professional and enthusiast programmers.
The current question title, which states your concerns about the code, applies to too many questions on this site to be useful. The site standard is for the title to simply state the task accomplished by the code. Please see How to Ask for examples, and revise the title accordingly.
– Zeta
42 mins ago
@Zeta: the question is from 2008, was migrated in 2012, just got upvoted and I decided to give it a little better title. And yeah, I know, this is a stupid question.
– abatishchev
24 mins ago
add a comment |
I develop next application parameters storing paradigm:
There is enum for each parameter roles
enum ParameterRole
{
FileName,
FileDir
}
Parameters are contained in special container as object
class ParamContainer : Dictionary(ParameterRole, object) {
public new object this[ParameterRole role]
{
get
{
if (base.ContainsKey(role))
{
return base[role];
}
else
{
return null;
}
}
set
{
if (base.ContainsKey(role))
{
base[role] = value;
}
else
{
base.Add(role, value);
}
}
}
}
It's private member of AppSettings class
class AppSettings {
ParamContainer container = new ParamContainer();
public string FileName
{
get
{
return container[ParemeterRole.FileName] as string;
}
set
{
container[ParemeterRole.FileName] = value;
}
}
}
and for each settings there is a corresponding property, but it works not with a local variable, but adds/gets a value from the container.
What benefits?
You can work with parameters separately as named property, so as list (container.Keys, container.Values) - it's useful for SQL queries and XML based business logic.
What deficiencies?
Parameter values are stored as object and it uses more memory as it could, I guess, if was stored as it's corresponding types.
What do you think about it? It's very interesting and important for me.
Is it rubbish or could be useful?
c#
asked Dec 27 '08 at 10:30
abatishchev
257111
I develop next application parameters storing paradigm:
There is enum for each parameter roles
enum ParameterRole
{
FileName,
FileDir
}
Parameters are contained in special container as object
class ParamContainer : Dictionary(ParameterRole, object) {
public new object this[ParameterRole role]
{
get
{
if (base.ContainsKey(role))
{
return base[role];
}
else
{
return null;
}
}
set
{
if (base.ContainsKey(role))
{
base[role] = value;
}
else
{
base.Add(role, value);
}
}
}
}
It's private member of AppSettings class
class AppSettings {
ParamContainer container = new ParamContainer();
public string FileName
{
get
{
return container[ParemeterRole.FileName] as string;
}
set
{
container[ParemeterRole.FileName] = value;
}
}
}
and for each settings there is a corresponding property, but it works not with a local variable, but adds/gets a value from the container.
What benefits?
You can work with parameters separately as named property, so as list (container.Keys, container.Values) - it's useful for SQL queries and XML based business logic.
What deficiencies?
Parameter values are stored as object and it uses more memory as it could, I guess, if was stored as it's corresponding types.
What do you think about it? It's very interesting and important for me.
Is it rubbish or could be useful?
c#
c#
asked Dec 27 '08 at 10:30
abatishchev
257111
asked Dec 27 '08 at 10:30
abatishchev
257111
edited 42 mins ago
asked Dec 27 '08 at 10:30
abatishchev
257111
asked Dec 27 '08 at 10:30
abatishchev
257111
asked Dec 27 '08 at 10:30
abatishchev
257111
257111
migrated from stackoverflow.com May 1 '12 at 2:09
This question came from our site for professional and enthusiast programmers.
migrated from stackoverflow.com May 1 '12 at 2:09
This question came from our site for professional and enthusiast programmers.
The current question title, which states your concerns about the code, applies to too many questions on this site to be useful. The site standard is for the title to simply state the task accomplished by the code. Please see How to Ask for examples, and revise the title accordingly.
– Zeta
42 mins ago
@Zeta: the question is from 2008, was migrated in 2012, just got upvoted and I decided to give it a little better title. And yeah, I know, this is a stupid question.
– abatishchev
24 mins ago
add a comment |
The current question title, which states your concerns about the code, applies to too many questions on this site to be useful. The site standard is for the title to simply state the task accomplished by the code. Please see How to Ask for examples, and revise the title accordingly.
– Zeta
42 mins ago
@Zeta: the question is from 2008, was migrated in 2012, just got upvoted and I decided to give it a little better title. And yeah, I know, this is a stupid question.
– abatishchev
24 mins ago
The current question title, which states your concerns about the code, applies to too many questions on this site to be useful. The site standard is for the title to simply state the task accomplished by the code. Please see How to Ask for examples, and revise the title accordingly.
– Zeta
42 mins ago
The current question title, which states your concerns about the code, applies to too many questions on this site to be useful. The site standard is for the title to simply state the task accomplished by the code. Please see How to Ask for examples, and revise the title accordingly.
– Zeta
42 mins ago
@Zeta: the question is from 2008, was migrated in 2012, just got upvoted and I decided to give it a little better title. And yeah, I know, this is a stupid question.
– abatishchev
24 mins ago
@Zeta: the question is from 2008, was migrated in 2012, just got upvoted and I decided to give it a little better title. And yeah, I know, this is a stupid question.
– abatishchev
24 mins ago
add a comment |
1 Answer
1
active
oldest
votes
Well, the use of an enum (ParameterRole) doesn't make it particularly re-usable in different scenarios; you could express the key simply via generics (<T>). Other than that, it is a fairly standard lookup / property-bag. So a fairly common and established pattern. The get/set logic is over-complicated, too:
get
{
object value;
TryGetValue(role, out value);
return value;
}
set
{
base[role] = value;
}
Finally, I'm a little dubious about inheriting from Dictionary<,> here - I'd probably just encapsulate it instead (i.e. contain a private Dictionary<,> field, but not derive from it).
answered Dec 27 '08 at 15:50
Marc Gravell♦
39116
Do you think making an inheritance to simplify access to dictionary's value is bad idea? My idea was that you can just use an operator without checking presence of given key. A lot of code once, a few code every time you set/get a value
– abatishchev
Dec 27 '08 at 16:01
Well, just using the basic indexer risks it blowing up (key-not-found). Your bespoke indexer avoids this, but that works equally well for encapsulation or inheritance. Really, though, the question might as well be "is there a reason to expose this as inheritance" - I can't think of any off-hand.
– Marc Gravell♦
Dec 27 '08 at 16:10
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
return StackExchange.using("mathjaxEditing", function () {
StackExchange.MarkdownEditor.creationCallbacks.add(function (editor, postfix) {
StackExchange.mathjaxEditing.prepareWmdForMathJax(editor, postfix, [["\$", "\$"]]);
});
});
}, "mathjax-editing");
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "196"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fcodereview.stackexchange.com%2fquestions%2f11361%2fis-my-parameters-model-good%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
Well, the use of an enum (ParameterRole) doesn't make it particularly re-usable in different scenarios; you could express the key simply via generics (<T>). Other than that, it is a fairly standard lookup / property-bag. So a fairly common and established pattern. The get/set logic is over-complicated, too:
get
{
object value;
TryGetValue(role, out value);
return value;
}
set
{
base[role] = value;
}
Finally, I'm a little dubious about inheriting from Dictionary<,> here - I'd probably just encapsulate it instead (i.e. contain a private Dictionary<,> field, but not derive from it).
answered Dec 27 '08 at 15:50
Marc Gravell♦
39116
Do you think making an inheritance to simplify access to dictionary's value is bad idea? My idea was that you can just use an operator without checking presence of given key. A lot of code once, a few code every time you set/get a value
– abatishchev
Dec 27 '08 at 16:01
Well, just using the basic indexer risks it blowing up (key-not-found). Your bespoke indexer avoids this, but that works equally well for encapsulation or inheritance. Really, though, the question might as well be "is there a reason to expose this as inheritance" - I can't think of any off-hand.
– Marc Gravell♦
Dec 27 '08 at 16:10
add a comment |
Well, the use of an enum (ParameterRole) doesn't make it particularly re-usable in different scenarios; you could express the key simply via generics (<T>). Other than that, it is a fairly standard lookup / property-bag. So a fairly common and established pattern. The get/set logic is over-complicated, too:
get
{
object value;
TryGetValue(role, out value);
return value;
}
set
{
base[role] = value;
}
Finally, I'm a little dubious about inheriting from Dictionary<,> here - I'd probably just encapsulate it instead (i.e. contain a private Dictionary<,> field, but not derive from it).
answered Dec 27 '08 at 15:50
Marc Gravell♦
39116
Do you think making an inheritance to simplify access to dictionary's value is bad idea? My idea was that you can just use an operator without checking presence of given key. A lot of code once, a few code every time you set/get a value
– abatishchev
Dec 27 '08 at 16:01
Well, just using the basic indexer risks it blowing up (key-not-found). Your bespoke indexer avoids this, but that works equally well for encapsulation or inheritance. Really, though, the question might as well be "is there a reason to expose this as inheritance" - I can't think of any off-hand.
– Marc Gravell♦
Dec 27 '08 at 16:10
add a comment |
Well, the use of an enum (ParameterRole) doesn't make it particularly re-usable in different scenarios; you could express the key simply via generics (<T>). Other than that, it is a fairly standard lookup / property-bag. So a fairly common and established pattern. The get/set logic is over-complicated, too:
get
{
object value;
TryGetValue(role, out value);
return value;
}
set
{
base[role] = value;
}
Finally, I'm a little dubious about inheriting from Dictionary<,> here - I'd probably just encapsulate it instead (i.e. contain a private Dictionary<,> field, but not derive from it).
answered Dec 27 '08 at 15:50
Marc Gravell♦
39116
Well, the use of an enum (ParameterRole) doesn't make it particularly re-usable in different scenarios; you could express the key simply via generics (<T>). Other than that, it is a fairly standard lookup / property-bag. So a fairly common and established pattern. The get/set logic is over-complicated, too:
get
{
object value;
TryGetValue(role, out value);
return value;
}
set
{
base[role] = value;
}
Finally, I'm a little dubious about inheriting from Dictionary<,> here - I'd probably just encapsulate it instead (i.e. contain a private Dictionary<,> field, but not derive from it).
answered Dec 27 '08 at 15:50
Marc Gravell♦
39116
answered Dec 27 '08 at 15:50
Marc Gravell♦
39116
answered Dec 27 '08 at 15:50
Marc Gravell♦
39116
answered Dec 27 '08 at 15:50
Marc Gravell♦
39116
39116
Do you think making an inheritance to simplify access to dictionary's value is bad idea? My idea was that you can just use an operator without checking presence of given key. A lot of code once, a few code every time you set/get a value
– abatishchev
Dec 27 '08 at 16:01
Well, just using the basic indexer risks it blowing up (key-not-found). Your bespoke indexer avoids this, but that works equally well for encapsulation or inheritance. Really, though, the question might as well be "is there a reason to expose this as inheritance" - I can't think of any off-hand.
– Marc Gravell♦
Dec 27 '08 at 16:10
add a comment |
Do you think making an inheritance to simplify access to dictionary's value is bad idea? My idea was that you can just use an operator without checking presence of given key. A lot of code once, a few code every time you set/get a value
– abatishchev
Dec 27 '08 at 16:01
Well, just using the basic indexer risks it blowing up (key-not-found). Your bespoke indexer avoids this, but that works equally well for encapsulation or inheritance. Really, though, the question might as well be "is there a reason to expose this as inheritance" - I can't think of any off-hand.
– Marc Gravell♦
Dec 27 '08 at 16:10
Do you think making an inheritance to simplify access to dictionary's value is bad idea? My idea was that you can just use an operator without checking presence of given key. A lot of code once, a few code every time you set/get a value
– abatishchev
Dec 27 '08 at 16:01
Do you think making an inheritance to simplify access to dictionary's value is bad idea? My idea was that you can just use an operator without checking presence of given key. A lot of code once, a few code every time you set/get a value
– abatishchev
Dec 27 '08 at 16:01
Well, just using the basic indexer risks it blowing up (key-not-found). Your bespoke indexer avoids this, but that works equally well for encapsulation or inheritance. Really, though, the question might as well be "is there a reason to expose this as inheritance" - I can't think of any off-hand.
– Marc Gravell♦
Dec 27 '08 at 16:10
Well, just using the basic indexer risks it blowing up (key-not-found). Your bespoke indexer avoids this, but that works equally well for encapsulation or inheritance. Really, though, the question might as well be "is there a reason to expose this as inheritance" - I can't think of any off-hand.
– Marc Gravell♦
Dec 27 '08 at 16:10
add a comment |
Thanks for contributing an answer to Code Review Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
Use MathJax to format equations. MathJax reference.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fcodereview.stackexchange.com%2fquestions%2f11361%2fis-my-parameters-model-good%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
The current question title, which states your concerns about the code, applies to too many questions on this site to be useful. The site standard is for the title to simply state the task accomplished by the code. Please see How to Ask for examples, and revise the title accordingly.
– Zeta
42 mins ago
@Zeta: the question is from 2008, was migrated in 2012, just got upvoted and I decided to give it a little better title. And yeah, I know, this is a stupid question.
– abatishchev
24 mins ago