Your idea about the openFileDialog and the XmlWriter sounds fine. Try to see what you can get.
Please, don't forget that each QuantProject application will invoke a single script. So think carefully about where to place your dialog manager.
I guess you mean the dialog to open only if the mdb location is not defined yet. What if you wish to move the mdb to a different location.
At first sight, a good solution might be to check if the mdb is present and with the up to date structure. If (and only if) not, the dialog should open up.
Let's elaborate about the script based structure update. It sounds like a must have feature, going to simplify the full management.
As a final, but IMPORTANT note, you should be aware that I'm trying to implement a n-tier structure.
It is really important to keep (and possibly improve) such an approach. So the dialog code should be placed in the proper tier.
As you've certainly noticed, I've prefixed the folders so that the alphabetic sorting of the names preserves the n-tier structure.
There is exactly a single dll for each single tier.
The code is thought so that each object in the m-tier can access only the objects in the (m-1)-tier and the objects in the ADT library (this library works somewhat aside from the n-tier structure).
Comments about the n-tier approach will be really appreciated.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
So, it seems to be a good solution to locate the mdb through the xml file placed within the same folder as the exe. It should be simple (at first sight) to manage the meaningful situations you happen to meet in trying to connect to a database file (I hope ...).
Far more complex (and important) the management of the mdb structure. What about in case you need to keep your data in an old QuantProject.mbd but you would like to use a new quantProject release that needs an mdb structure of a different type?
Think about the following ideas (in order to get the maximum both from CVS and .Net capabilities):
-tagging the mdb module with two numbers (ss);
-tagging the quantProject module with four numbers: ss.xx. The first 2 numbers mean that the program needs a ss type of mdb. The other two numbers mean that the mdb file can be used by any assembly version that contains the same two first numbers;
- the mdb contains a table with one field in which you store the mdb's version structure;
- the script program will change the mdb structure if and only if exe's assembly version is cc.xx (being cc = ss+1 and ss the actual version number stored in the mdb file).
Think about that and tell me what you think.
The n-tier structure of the solution seems to be interesting. Tell me more about that: what happens if I try to access object in a different tier (m-2. e.g.)? I mean: is this structure only at developer-level or also at code-level, in some way that tells you are linking to the wrong tier?
Millo
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
About the tagging idea, it looks really interesting. Admittedly, I'm not much acknowledged about CVS tagging.
All documentation I've read about CVS, reports something like the following: "you will probably never need using tagging". So I need to read more about this feature.If you alread have a link to the specific documentation, please provide me with it.
As a final note, it would be wise not to reinvent the wheel. No doubt your solution sounds effective, but the database versioning maintenance looks like a wide spread problem, so I guess it has already been tackled in the .Net environment. Did you get the overall framework idea somewhere on the net? If not, it would be interesting to read some article specifically devoted to this topic (with pros and cons of different solutions).
I'm not an n-tier guru but I can see the undoubtable advantages: if you, for any reason, change the m-tier project, then you (at most) need to only change the (m+1)-tier.
Unfortunately, my understanding is that object oriented programming loses a large part of its power this way: not all objects can interact with every other objects.
But be aware that if you don't use such a structure, you will run into a lot of cyclic reference compile errors (when the project has progressively became more complex, it has been a nightmare to keep the full thing to compile). Of course, a solution to the compile issue would be to use a single large project, but it would result in loooong compile time and less flexibility in development distribution among different developers.
>is this structure only at developer-level
>or also at code-level, in some way that
>tells you are linking to the wrong tier
This is a good point: unfortunately it is only at developer-level. I would be surprised if there was a way to obtain this constraint in the .Net framework (but I would be happy to be surprised...)
I believe we need an automatic .Net to UML converter to manage this type of problems and to keep the full structure easy to understand. Please help me looking if we can find such a tool (of course better if we can find it open source, possibly written in C#).
As a final note, I've just clicked on the SourceForge option to monitor this forum. Please consider doing the same. (I guess that "Monitor this forum" means something like "Send me an email when a new post is submitted").
Until now I've not been able to receive automatic emails from SourceForge, but I believe I will solve the issue in the next future.
Bye for now.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'd like to write some code that should simplify related files' management (a class which retrieves/writes paths from/to a little xml file in the same directory as the exe). In order to make practice with some powerful .net classes, like XmlWriter and XmlReader ... and to learn how your solution works in suggesting me to find good trading strategies.
But I find it difficult to search for a good position of my file (called, let's say, FileLocator.cs) within your solution. I've seen that in your solution you need to link to some other files (not only the QuantProject.mdb): so what about the n- tier structure, if it happens that two different projects need to link to different files (and thus need to use my class)?
In other words: you 've created the ADT project which contains objects that can be used by any of the other projects. So that Project may be the natural location of my file.
What can you tell me?
Marco
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm afraid we are having some problems with the the n-tier approach because we mainly are building a library, not a full application.
But it looks anyway important to keep such a strategy.
As far as I can see, the best place for FileLocator.cs is within the DataAccess tier (b2 prefix).
I would like this tier to be the only one directly accessing the DB. Assume we add MySql support: it would be safe if we had to change only the DataAccess tier.
What about the following approach?
The first time the application accesses the database, the DataBase class checks for the db location, db proper version and so on.
If the db is not present, your FileLocator.cs (DataBaseLocator.cs may be a better choice) is invoked.
If the db has not the proper version, database scripts are run accordingly.
I mean, it would be nice to have something handled directly by the DataBase class, so that it will result completely transparent to the tiers above.
Please, let me know your comments about such an approach.
Glauco
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Ok Glauco, your approach is good.
Although we could achieve with this "problem" in the future: similar code's areas repeated through out the solution. I say: we could, not we will. But I 'd like to know your ideas about this possible problem.
I mean: let's suppose you need to access a txt file (or any file). Some methods, property and fields will be similar to the methods, property and fields I'm going to implement within the DataBaseLocator class. So you lose the flexibility of OOP, if there is a constraint (the n-tier structure) that forces you to write another class, TxtFileLocator (for example) within a certain project.
I realize, on the other hand, that the n-tier solution is a very good choice (and I like it very much) in order to keep independence of code sections (achieving a lot of advantages - reducing compiling time, you teach me ..., reducing the risk of headache in case you need to change some code lines, simplifing the team development ... and so on). There are pros and cons, as in everything.
Bye
Marco
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Ok Millo,
I move our topic to this public forum.
Your idea about the openFileDialog and the XmlWriter sounds fine. Try to see what you can get.
Please, don't forget that each QuantProject application will invoke a single script. So think carefully about where to place your dialog manager.
I guess you mean the dialog to open only if the mdb location is not defined yet. What if you wish to move the mdb to a different location.
At first sight, a good solution might be to check if the mdb is present and with the up to date structure. If (and only if) not, the dialog should open up.
Let's elaborate about the script based structure update. It sounds like a must have feature, going to simplify the full management.
As a final, but IMPORTANT note, you should be aware that I'm trying to implement a n-tier structure.
It is really important to keep (and possibly improve) such an approach. So the dialog code should be placed in the proper tier.
As you've certainly noticed, I've prefixed the folders so that the alphabetic sorting of the names preserves the n-tier structure.
There is exactly a single dll for each single tier.
The code is thought so that each object in the m-tier can access only the objects in the (m-1)-tier and the objects in the ADT library (this library works somewhat aside from the n-tier structure).
Comments about the n-tier approach will be really appreciated.
Hi Glauco,
So, it seems to be a good solution to locate the mdb through the xml file placed within the same folder as the exe. It should be simple (at first sight) to manage the meaningful situations you happen to meet in trying to connect to a database file (I hope ...).
Far more complex (and important) the management of the mdb structure. What about in case you need to keep your data in an old QuantProject.mbd but you would like to use a new quantProject release that needs an mdb structure of a different type?
Think about the following ideas (in order to get the maximum both from CVS and .Net capabilities):
-tagging the mdb module with two numbers (ss);
-tagging the quantProject module with four numbers: ss.xx. The first 2 numbers mean that the program needs a ss type of mdb. The other two numbers mean that the mdb file can be used by any assembly version that contains the same two first numbers;
- the mdb contains a table with one field in which you store the mdb's version structure;
- the script program will change the mdb structure if and only if exe's assembly version is cc.xx (being cc = ss+1 and ss the actual version number stored in the mdb file).
Think about that and tell me what you think.
The n-tier structure of the solution seems to be interesting. Tell me more about that: what happens if I try to access object in a different tier (m-2. e.g.)? I mean: is this structure only at developer-level or also at code-level, in some way that tells you are linking to the wrong tier?
Millo
About the tagging idea, it looks really interesting. Admittedly, I'm not much acknowledged about CVS tagging.
All documentation I've read about CVS, reports something like the following: "you will probably never need using tagging". So I need to read more about this feature.If you alread have a link to the specific documentation, please provide me with it.
As a final note, it would be wise not to reinvent the wheel. No doubt your solution sounds effective, but the database versioning maintenance looks like a wide spread problem, so I guess it has already been tackled in the .Net environment. Did you get the overall framework idea somewhere on the net? If not, it would be interesting to read some article specifically devoted to this topic (with pros and cons of different solutions).
I'm not an n-tier guru but I can see the undoubtable advantages: if you, for any reason, change the m-tier project, then you (at most) need to only change the (m+1)-tier.
Unfortunately, my understanding is that object oriented programming loses a large part of its power this way: not all objects can interact with every other objects.
But be aware that if you don't use such a structure, you will run into a lot of cyclic reference compile errors (when the project has progressively became more complex, it has been a nightmare to keep the full thing to compile). Of course, a solution to the compile issue would be to use a single large project, but it would result in loooong compile time and less flexibility in development distribution among different developers.
>is this structure only at developer-level
>or also at code-level, in some way that
>tells you are linking to the wrong tier
This is a good point: unfortunately it is only at developer-level. I would be surprised if there was a way to obtain this constraint in the .Net framework (but I would be happy to be surprised...)
I believe we need an automatic .Net to UML converter to manage this type of problems and to keep the full structure easy to understand. Please help me looking if we can find such a tool (of course better if we can find it open source, possibly written in C#).
As a final note, I've just clicked on the SourceForge option to monitor this forum. Please consider doing the same. (I guess that "Monitor this forum" means something like "Send me an email when a new post is submitted").
Until now I've not been able to receive automatic emails from SourceForge, but I believe I will solve the issue in the next future.
Bye for now.
Hi Glauco
I'd like to write some code that should simplify related files' management (a class which retrieves/writes paths from/to a little xml file in the same directory as the exe). In order to make practice with some powerful .net classes, like XmlWriter and XmlReader ... and to learn how your solution works in suggesting me to find good trading strategies.
But I find it difficult to search for a good position of my file (called, let's say, FileLocator.cs) within your solution. I've seen that in your solution you need to link to some other files (not only the QuantProject.mdb): so what about the n- tier structure, if it happens that two different projects need to link to different files (and thus need to use my class)?
In other words: you 've created the ADT project which contains objects that can be used by any of the other projects. So that Project may be the natural location of my file.
What can you tell me?
Marco
I'm afraid we are having some problems with the the n-tier approach because we mainly are building a library, not a full application.
But it looks anyway important to keep such a strategy.
As far as I can see, the best place for FileLocator.cs is within the DataAccess tier (b2 prefix).
I would like this tier to be the only one directly accessing the DB. Assume we add MySql support: it would be safe if we had to change only the DataAccess tier.
What about the following approach?
The first time the application accesses the database, the DataBase class checks for the db location, db proper version and so on.
If the db is not present, your FileLocator.cs (DataBaseLocator.cs may be a better choice) is invoked.
If the db has not the proper version, database scripts are run accordingly.
I mean, it would be nice to have something handled directly by the DataBase class, so that it will result completely transparent to the tiers above.
Please, let me know your comments about such an approach.
Glauco
Ok Glauco, your approach is good.
Although we could achieve with this "problem" in the future: similar code's areas repeated through out the solution. I say: we could, not we will. But I 'd like to know your ideas about this possible problem.
I mean: let's suppose you need to access a txt file (or any file). Some methods, property and fields will be similar to the methods, property and fields I'm going to implement within the DataBaseLocator class. So you lose the flexibility of OOP, if there is a constraint (the n-tier structure) that forces you to write another class, TxtFileLocator (for example) within a certain project.
I realize, on the other hand, that the n-tier solution is a very good choice (and I like it very much) in order to keep independence of code sections (achieving a lot of advantages - reducing compiling time, you teach me ..., reducing the risk of headache in case you need to change some code lines, simplifing the team development ... and so on). There are pros and cons, as in everything.
Bye
Marco