Coffeehouse Thread

6 posts

Forum Read Only

This forum has been made read only by the site admins. No new threads or comments can be added.

Reading local files -- Win API's Vs Framework

Back to Forum: Coffeehouse
  • User profile image
    risu

    Hello All,

    Sorry if the question is a bit simplistic, trivial or too long.

    I'm working on a multi devoloper project and am getting ready to fight for a change that although I believe in I'm not too sure is totally neccesary.

    Unfortunately the project did not have a very indepth design proccess and we devolopers were pretty much left to our own to build our parts. We're getting close to the integration time and all of the differences are starting to get noticed big time.

    Okay the situation. All the parts of the program have to access two servers for their information. My access solution was to create an DatabaseAccess class that uses the connection string as a constant and then use that constant anywhere needed. I figured that any changes to the Database Connection could be made in one location, recompile the DLL and distribute.

    Another devolper has gone the route of a local ini file (which my project manager likes). Thus he can siply change the ini file and relaunch the program. Test to production in a heartbeat. He understands that this exposes the DB login information in plain text and wants to write an encryption function to handle this. I think this is the direction we're going to end up going in.

    Here's the part I'm concerned about. When I asked him how he was reading the ini file he sent me the code and he's using WIN API's to access the file.

    I do not feel that in the .NET environment we should be using API's when we can avoid them (especially in this case of file access which is well supported by .NET). However I have no solid evidence that it would hurt performance or is a "Bad Thing".

    This developer is also a Senior Devoloper who is very good and respected in the shop. It not easy to suggest the change to the framework mode as both the project manager and senior devoloper in question are not as experienced in either the .Net framework or Object orientated coding. The general belief is, "if it works and we can do the same thing we did in VB 6 then it's good".

    I'd appreciate any comments you guys/gals might have on the issue of API vs Framework


  • User profile image
    ZippyV

    Importing dll's and unmanaged code is bad for performance.
    Also, you have to describe what your program needs access to (for security reasons). You can set your program to use some isolated storage space, for example. But you can't use those features if they are in unmanaged code (-> api's).
    Have you used FxCop from gotdotnet? It analyses the code and gives suggestions to improve it.

  • User profile image
    GooberDLX

    You wouldnt have to worry about connections and passwords using a DSN... then have your connection string reference it..

    .Net has built in configuration system, in which you could encrypt/decrypt the connection string too..

    http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpref/html/frlrfsystemconfiguration.asp

    I agree with your coworker and manager, having to recompile and redistribute just because of a connection string change is not optimal. BUT I dont suggest using the old API for it..

    Jake

  • User profile image
    Blkbam

    risu wrote:

    Another devolper has gone the route of a local ini file (which my project manager likes). Thus he can siply change the ini file and relaunch the program. Test to production in a heartbeat. He understands that this exposes the DB login information in plain text and wants to write an encryption function to handle this. I think this is the direction we're going to end up going in.


    The ini approach is definitely the way to go. It allows the use of multi-environments and customization of authentication, which clients love (keyword "security").  In my shop we use something like this:

    [dsn]
    dsn1=something

    [dsn1]
    user=user
    pwd=password

    The username and password are both encrypted so there isn't the slightest bit of authentication data visible to the user.

    As far as API vs Framework, I've stuck with the API method for now.  Some old habits are hard to break and I've grown accustom to using the API for simple methods while other more complex methods I use the Framework.

    Something as simple as reading an INI file shouldn't make much difference in performance.  From the API you can only read a 255-character string from each key so you aren't moving much data back and forth.

    No if you are looking for consistency through the whole app and want to use only the Framework then I guess you have an argument.  If you really want to confirm to the .Net standard, from what I've read, you wouldn’t use ini files within but xml files or Isolated Storage.

  • User profile image
    risu

    Thank you for the feedback. I'd appreciate it as well if anyone else has anything else, even reiterations of previous posters.

    I know that the dll method isn't the greatest. I'd like to do in line with OOP style but I'm not really sure what the preferred OOP way would be. I'll look into the System.Configuration to see if that will solve our problem.

    I'm also afraid that the use of API for a local read may be a sign that the senior devoloper has used API in other places that framework may have already covered.

    If I may have some leeway I'd like to extend the question a little bit to include this:

    Upon further discussion it is not intended for every connection to call the ReadFile function when it's created. I was kinda afraid of this (are loacal file reads for every connection object neccessarily bad?). Instead they will have a top level Module (not class or form) firing off the overall program. The module will read the local file (through whatever method is decided upon) and fill a global variable that will be used by all forms called subsequently.

    Thoughts on this?

    I'm not thrilled with it as it seems to go against OOP standards and practices. Then again I'm still new at this so I could be completely wrong.

    Again Thanks for the time spent informing this new programmer.

    Thanks,
    Risu

  • User profile image
    GooberDLX

    risu wrote:

    Upon further discussion it is not intended for every connection to call the ReadFile function when it's created. I was kinda afraid of this (are loacal file reads for every connection object neccessarily bad?). Instead they will have a top level Module (not class or form) firing off the overall program. The module will read the local file (through whatever method is decided upon) and fill a global variable that will be used by all forms called subsequently.

    Thoughts on this?


    Well.. File System I/O has always been saught at as expensive.. Path Lookups, Authorization Checks, etc...

    By what you have said so far, it seems as though your settings arent going to change that frequently anyway, so reading it in once would be sufficient. The System.Configuration namespace is wonderful at those types of applications...

    If you were to think on an object oriented level, you would have your object that handles data, read the config file on construction... or if you read it in at an application level, its already in memory so it would just have to be passed or referenced..

    Jake

Conversation locked

This conversation has been locked by the site admins. No new comments can be made.