Data table retrieval using column name or integer












0















So, just looking for a general rule of thumb here, and could not seem to find a legitimate method to go forward with. I see both often.



Essentially you have something like this:



DataTable dt = new DataTable();
dt blah blah blah .Fill


Now accessing:



dt.Rows[i]["ColumnName"].ToString();
dt.Rows[i][ColumnInteger].ToString();


So the question is, I see the merits of both. Changing a column name in the table one day, would have no effect if we had been using the integer. On the same side, using the column name definitely seems easier from a readability side. Or maybe there is a reason to pick one over the other from a performance perspective.



So really, what do you all see in consistent practice?










share|improve this question





























    0















    So, just looking for a general rule of thumb here, and could not seem to find a legitimate method to go forward with. I see both often.



    Essentially you have something like this:



    DataTable dt = new DataTable();
    dt blah blah blah .Fill


    Now accessing:



    dt.Rows[i]["ColumnName"].ToString();
    dt.Rows[i][ColumnInteger].ToString();


    So the question is, I see the merits of both. Changing a column name in the table one day, would have no effect if we had been using the integer. On the same side, using the column name definitely seems easier from a readability side. Or maybe there is a reason to pick one over the other from a performance perspective.



    So really, what do you all see in consistent practice?










    share|improve this question



























      0












      0








      0








      So, just looking for a general rule of thumb here, and could not seem to find a legitimate method to go forward with. I see both often.



      Essentially you have something like this:



      DataTable dt = new DataTable();
      dt blah blah blah .Fill


      Now accessing:



      dt.Rows[i]["ColumnName"].ToString();
      dt.Rows[i][ColumnInteger].ToString();


      So the question is, I see the merits of both. Changing a column name in the table one day, would have no effect if we had been using the integer. On the same side, using the column name definitely seems easier from a readability side. Or maybe there is a reason to pick one over the other from a performance perspective.



      So really, what do you all see in consistent practice?










      share|improve this question
















      So, just looking for a general rule of thumb here, and could not seem to find a legitimate method to go forward with. I see both often.



      Essentially you have something like this:



      DataTable dt = new DataTable();
      dt blah blah blah .Fill


      Now accessing:



      dt.Rows[i]["ColumnName"].ToString();
      dt.Rows[i][ColumnInteger].ToString();


      So the question is, I see the merits of both. Changing a column name in the table one day, would have no effect if we had been using the integer. On the same side, using the column name definitely seems easier from a readability side. Or maybe there is a reason to pick one over the other from a performance perspective.



      So really, what do you all see in consistent practice?







      c# sql datatable






      share|improve this question















      share|improve this question













      share|improve this question




      share|improve this question








      edited Nov 13 '18 at 18:47









      Erik Philips

      41k691124




      41k691124










      asked Nov 13 '18 at 18:44









      CMRCMR

      859




      859
























          2 Answers
          2






          active

          oldest

          votes


















          1















          So really, what do you all see in consistent practice?




          They both exist for a reason, they're both useful when the other isn't. You're always going to be tightly coupled to a table in SQL land. It's just your choice if you want to couple it via column index or string.



          In practice, I've never designed a system to use Data Tables. I have a strongly typed Object Oriented Language so I choose to use objects over generic data containers.



          There are ORM frameworks like Entity Framework (microsoft), Dapper, NHibernate and more that allow your Database Row (XML nodes, Json Object etc) to represent a .net Object (defined, anonymous and sometimes Tuples). The goal is to take a data from a storage system system and convert your request into a class. After retrieving data;



          A Data Table Might look like:



          [1]Id     [2]FirstName         [3]LastName
          (int) (string) (string)
          --------------------------------------------
          1 Erik Philips


          So computing a Full Name becomes code that looks like:



          var fullName = $"{dt.Rows[i][2].ToString()} {dt.Rows[i][3].ToString()}";


          or



          var fullName = $"{dt.Rows[i]["FirstName"].ToString()} {dt.Rows[i]["LastName"].ToString()}";


          Which does it's job but the logic in an Object Oriented Language should be encapsulated. Using an ORM your data is requested via a class that represents data access and is configured to get the data and map it (which I won't go into detail about the specifics). First you start by creating a POCO:



          public class Person
          {
          public int Id { get; set; }
          public string FirstName { get; set; }
          public string LastName { get; set; }
          }


          and then you ask for them via the Data Access Class;



          Entity Framework (DbContext)



          var person = DbContext.Persons.FirstOrDefault(p => p.id == 1);
          // OR
          var person = DbContext.Set<Person>().FirstOrDefault(p => p.id == 1);


          Dapper: (*I've not used dapper so this might be technically wrong but you get the idea)



          var person = connection.Query<Person>("Select * FROM CUSTOMERS WHERE Id = 1").FirstOrDefault()


          NHibernate:



          var person = session.Get<Person>(Id);


          In all these instances you get back a Person class/object. Now we can encapsulate business logic (we need to have a consistent way to represent "Full Name" to our data consumers).



          public class Person
          {
          public int Id { get; set; }
          public string FirstName { get; set; }
          public string LastName { get; set; }
          public DateTime BornOn { get; set; }
          public boolean IsMarried { get; set; }
          public string FullName
          {
          get
          {
          return $"{FirstName} {LastName}";
          }
          }
          }



          but is that the main goal of it all?




          In my personal opinion, the goal of it all is to aid the developer writing good code, which includes (items relevant to the question I'll comment on);



          using the S.O.L.I.D. Principles:



          Single responsibility principle



          // What else could this class possibly be used for?
          public class Person ....


          Writing readable code with as little documentation as possible.



          var tom = dbContext.Persons.FirstOrDefault(p => p.FirstName == "Tom");

          if (tom.IsMarried) ...

          if (tom.BornOn > DateTime.Now) ...





          share|improve this answer


























          • To add to what @Erik is saying in the last paragraph: I like using Entity Framework for working with objects.

            – MikeH
            Nov 13 '18 at 18:54








          • 1





            Ty for this answer as well. Sensible response. I think the below post works better in this case. But understand what you are saying. I have marked an answer, but feel free to post any small samples, I am sure others wonder this as well.

            – CMR
            Nov 13 '18 at 20:04













          • Yeah mark whatever answer works for you :)

            – Erik Philips
            Nov 13 '18 at 20:51











          • @ErikPhilips gorgeous example. Thank you for editing that. I think for the most part I follow what is going on here. So then from a comparison standpoint, is your example for readability and following OOP practices? Like when you show accessing from the data table, I can quickly see how much more ugly and confusing that looks versus the thought out approach, but is that the main goal of it all?

            – CMR
            Nov 14 '18 at 15:06











          • Lightly updated my answer based on your question.

            – Erik Philips
            Nov 14 '18 at 18:15



















          1














          This won't answer the "what is the right way" question, but if you want to maintain readability while still using indexes you could create an enum:



          enum ColumnNames
          {
          FirstName = 1,
          LastName =2,
          }

          dt.Rows[i][(int)ColumnNames.FirstName].ToString();





          share|improve this answer
























          • Love it, using it, this is the right way lol. Best of both worlds here.

            – CMR
            Nov 13 '18 at 20:01











          Your Answer






          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: "1"
          };
          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: true,
          noModals: true,
          showLowRepImageUploadWarning: true,
          reputationToPostImages: 10,
          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
          });


          }
          });














          draft saved

          draft discarded


















          StackExchange.ready(
          function () {
          StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53287608%2fdata-table-retrieval-using-column-name-or-integer%23new-answer', 'question_page');
          }
          );

          Post as a guest















          Required, but never shown

























          2 Answers
          2






          active

          oldest

          votes








          2 Answers
          2






          active

          oldest

          votes









          active

          oldest

          votes






          active

          oldest

          votes









          1















          So really, what do you all see in consistent practice?




          They both exist for a reason, they're both useful when the other isn't. You're always going to be tightly coupled to a table in SQL land. It's just your choice if you want to couple it via column index or string.



          In practice, I've never designed a system to use Data Tables. I have a strongly typed Object Oriented Language so I choose to use objects over generic data containers.



          There are ORM frameworks like Entity Framework (microsoft), Dapper, NHibernate and more that allow your Database Row (XML nodes, Json Object etc) to represent a .net Object (defined, anonymous and sometimes Tuples). The goal is to take a data from a storage system system and convert your request into a class. After retrieving data;



          A Data Table Might look like:



          [1]Id     [2]FirstName         [3]LastName
          (int) (string) (string)
          --------------------------------------------
          1 Erik Philips


          So computing a Full Name becomes code that looks like:



          var fullName = $"{dt.Rows[i][2].ToString()} {dt.Rows[i][3].ToString()}";


          or



          var fullName = $"{dt.Rows[i]["FirstName"].ToString()} {dt.Rows[i]["LastName"].ToString()}";


          Which does it's job but the logic in an Object Oriented Language should be encapsulated. Using an ORM your data is requested via a class that represents data access and is configured to get the data and map it (which I won't go into detail about the specifics). First you start by creating a POCO:



          public class Person
          {
          public int Id { get; set; }
          public string FirstName { get; set; }
          public string LastName { get; set; }
          }


          and then you ask for them via the Data Access Class;



          Entity Framework (DbContext)



          var person = DbContext.Persons.FirstOrDefault(p => p.id == 1);
          // OR
          var person = DbContext.Set<Person>().FirstOrDefault(p => p.id == 1);


          Dapper: (*I've not used dapper so this might be technically wrong but you get the idea)



          var person = connection.Query<Person>("Select * FROM CUSTOMERS WHERE Id = 1").FirstOrDefault()


          NHibernate:



          var person = session.Get<Person>(Id);


          In all these instances you get back a Person class/object. Now we can encapsulate business logic (we need to have a consistent way to represent "Full Name" to our data consumers).



          public class Person
          {
          public int Id { get; set; }
          public string FirstName { get; set; }
          public string LastName { get; set; }
          public DateTime BornOn { get; set; }
          public boolean IsMarried { get; set; }
          public string FullName
          {
          get
          {
          return $"{FirstName} {LastName}";
          }
          }
          }



          but is that the main goal of it all?




          In my personal opinion, the goal of it all is to aid the developer writing good code, which includes (items relevant to the question I'll comment on);



          using the S.O.L.I.D. Principles:



          Single responsibility principle



          // What else could this class possibly be used for?
          public class Person ....


          Writing readable code with as little documentation as possible.



          var tom = dbContext.Persons.FirstOrDefault(p => p.FirstName == "Tom");

          if (tom.IsMarried) ...

          if (tom.BornOn > DateTime.Now) ...





          share|improve this answer


























          • To add to what @Erik is saying in the last paragraph: I like using Entity Framework for working with objects.

            – MikeH
            Nov 13 '18 at 18:54








          • 1





            Ty for this answer as well. Sensible response. I think the below post works better in this case. But understand what you are saying. I have marked an answer, but feel free to post any small samples, I am sure others wonder this as well.

            – CMR
            Nov 13 '18 at 20:04













          • Yeah mark whatever answer works for you :)

            – Erik Philips
            Nov 13 '18 at 20:51











          • @ErikPhilips gorgeous example. Thank you for editing that. I think for the most part I follow what is going on here. So then from a comparison standpoint, is your example for readability and following OOP practices? Like when you show accessing from the data table, I can quickly see how much more ugly and confusing that looks versus the thought out approach, but is that the main goal of it all?

            – CMR
            Nov 14 '18 at 15:06











          • Lightly updated my answer based on your question.

            – Erik Philips
            Nov 14 '18 at 18:15
















          1















          So really, what do you all see in consistent practice?




          They both exist for a reason, they're both useful when the other isn't. You're always going to be tightly coupled to a table in SQL land. It's just your choice if you want to couple it via column index or string.



          In practice, I've never designed a system to use Data Tables. I have a strongly typed Object Oriented Language so I choose to use objects over generic data containers.



          There are ORM frameworks like Entity Framework (microsoft), Dapper, NHibernate and more that allow your Database Row (XML nodes, Json Object etc) to represent a .net Object (defined, anonymous and sometimes Tuples). The goal is to take a data from a storage system system and convert your request into a class. After retrieving data;



          A Data Table Might look like:



          [1]Id     [2]FirstName         [3]LastName
          (int) (string) (string)
          --------------------------------------------
          1 Erik Philips


          So computing a Full Name becomes code that looks like:



          var fullName = $"{dt.Rows[i][2].ToString()} {dt.Rows[i][3].ToString()}";


          or



          var fullName = $"{dt.Rows[i]["FirstName"].ToString()} {dt.Rows[i]["LastName"].ToString()}";


          Which does it's job but the logic in an Object Oriented Language should be encapsulated. Using an ORM your data is requested via a class that represents data access and is configured to get the data and map it (which I won't go into detail about the specifics). First you start by creating a POCO:



          public class Person
          {
          public int Id { get; set; }
          public string FirstName { get; set; }
          public string LastName { get; set; }
          }


          and then you ask for them via the Data Access Class;



          Entity Framework (DbContext)



          var person = DbContext.Persons.FirstOrDefault(p => p.id == 1);
          // OR
          var person = DbContext.Set<Person>().FirstOrDefault(p => p.id == 1);


          Dapper: (*I've not used dapper so this might be technically wrong but you get the idea)



          var person = connection.Query<Person>("Select * FROM CUSTOMERS WHERE Id = 1").FirstOrDefault()


          NHibernate:



          var person = session.Get<Person>(Id);


          In all these instances you get back a Person class/object. Now we can encapsulate business logic (we need to have a consistent way to represent "Full Name" to our data consumers).



          public class Person
          {
          public int Id { get; set; }
          public string FirstName { get; set; }
          public string LastName { get; set; }
          public DateTime BornOn { get; set; }
          public boolean IsMarried { get; set; }
          public string FullName
          {
          get
          {
          return $"{FirstName} {LastName}";
          }
          }
          }



          but is that the main goal of it all?




          In my personal opinion, the goal of it all is to aid the developer writing good code, which includes (items relevant to the question I'll comment on);



          using the S.O.L.I.D. Principles:



          Single responsibility principle



          // What else could this class possibly be used for?
          public class Person ....


          Writing readable code with as little documentation as possible.



          var tom = dbContext.Persons.FirstOrDefault(p => p.FirstName == "Tom");

          if (tom.IsMarried) ...

          if (tom.BornOn > DateTime.Now) ...





          share|improve this answer


























          • To add to what @Erik is saying in the last paragraph: I like using Entity Framework for working with objects.

            – MikeH
            Nov 13 '18 at 18:54








          • 1





            Ty for this answer as well. Sensible response. I think the below post works better in this case. But understand what you are saying. I have marked an answer, but feel free to post any small samples, I am sure others wonder this as well.

            – CMR
            Nov 13 '18 at 20:04













          • Yeah mark whatever answer works for you :)

            – Erik Philips
            Nov 13 '18 at 20:51











          • @ErikPhilips gorgeous example. Thank you for editing that. I think for the most part I follow what is going on here. So then from a comparison standpoint, is your example for readability and following OOP practices? Like when you show accessing from the data table, I can quickly see how much more ugly and confusing that looks versus the thought out approach, but is that the main goal of it all?

            – CMR
            Nov 14 '18 at 15:06











          • Lightly updated my answer based on your question.

            – Erik Philips
            Nov 14 '18 at 18:15














          1












          1








          1








          So really, what do you all see in consistent practice?




          They both exist for a reason, they're both useful when the other isn't. You're always going to be tightly coupled to a table in SQL land. It's just your choice if you want to couple it via column index or string.



          In practice, I've never designed a system to use Data Tables. I have a strongly typed Object Oriented Language so I choose to use objects over generic data containers.



          There are ORM frameworks like Entity Framework (microsoft), Dapper, NHibernate and more that allow your Database Row (XML nodes, Json Object etc) to represent a .net Object (defined, anonymous and sometimes Tuples). The goal is to take a data from a storage system system and convert your request into a class. After retrieving data;



          A Data Table Might look like:



          [1]Id     [2]FirstName         [3]LastName
          (int) (string) (string)
          --------------------------------------------
          1 Erik Philips


          So computing a Full Name becomes code that looks like:



          var fullName = $"{dt.Rows[i][2].ToString()} {dt.Rows[i][3].ToString()}";


          or



          var fullName = $"{dt.Rows[i]["FirstName"].ToString()} {dt.Rows[i]["LastName"].ToString()}";


          Which does it's job but the logic in an Object Oriented Language should be encapsulated. Using an ORM your data is requested via a class that represents data access and is configured to get the data and map it (which I won't go into detail about the specifics). First you start by creating a POCO:



          public class Person
          {
          public int Id { get; set; }
          public string FirstName { get; set; }
          public string LastName { get; set; }
          }


          and then you ask for them via the Data Access Class;



          Entity Framework (DbContext)



          var person = DbContext.Persons.FirstOrDefault(p => p.id == 1);
          // OR
          var person = DbContext.Set<Person>().FirstOrDefault(p => p.id == 1);


          Dapper: (*I've not used dapper so this might be technically wrong but you get the idea)



          var person = connection.Query<Person>("Select * FROM CUSTOMERS WHERE Id = 1").FirstOrDefault()


          NHibernate:



          var person = session.Get<Person>(Id);


          In all these instances you get back a Person class/object. Now we can encapsulate business logic (we need to have a consistent way to represent "Full Name" to our data consumers).



          public class Person
          {
          public int Id { get; set; }
          public string FirstName { get; set; }
          public string LastName { get; set; }
          public DateTime BornOn { get; set; }
          public boolean IsMarried { get; set; }
          public string FullName
          {
          get
          {
          return $"{FirstName} {LastName}";
          }
          }
          }



          but is that the main goal of it all?




          In my personal opinion, the goal of it all is to aid the developer writing good code, which includes (items relevant to the question I'll comment on);



          using the S.O.L.I.D. Principles:



          Single responsibility principle



          // What else could this class possibly be used for?
          public class Person ....


          Writing readable code with as little documentation as possible.



          var tom = dbContext.Persons.FirstOrDefault(p => p.FirstName == "Tom");

          if (tom.IsMarried) ...

          if (tom.BornOn > DateTime.Now) ...





          share|improve this answer
















          So really, what do you all see in consistent practice?




          They both exist for a reason, they're both useful when the other isn't. You're always going to be tightly coupled to a table in SQL land. It's just your choice if you want to couple it via column index or string.



          In practice, I've never designed a system to use Data Tables. I have a strongly typed Object Oriented Language so I choose to use objects over generic data containers.



          There are ORM frameworks like Entity Framework (microsoft), Dapper, NHibernate and more that allow your Database Row (XML nodes, Json Object etc) to represent a .net Object (defined, anonymous and sometimes Tuples). The goal is to take a data from a storage system system and convert your request into a class. After retrieving data;



          A Data Table Might look like:



          [1]Id     [2]FirstName         [3]LastName
          (int) (string) (string)
          --------------------------------------------
          1 Erik Philips


          So computing a Full Name becomes code that looks like:



          var fullName = $"{dt.Rows[i][2].ToString()} {dt.Rows[i][3].ToString()}";


          or



          var fullName = $"{dt.Rows[i]["FirstName"].ToString()} {dt.Rows[i]["LastName"].ToString()}";


          Which does it's job but the logic in an Object Oriented Language should be encapsulated. Using an ORM your data is requested via a class that represents data access and is configured to get the data and map it (which I won't go into detail about the specifics). First you start by creating a POCO:



          public class Person
          {
          public int Id { get; set; }
          public string FirstName { get; set; }
          public string LastName { get; set; }
          }


          and then you ask for them via the Data Access Class;



          Entity Framework (DbContext)



          var person = DbContext.Persons.FirstOrDefault(p => p.id == 1);
          // OR
          var person = DbContext.Set<Person>().FirstOrDefault(p => p.id == 1);


          Dapper: (*I've not used dapper so this might be technically wrong but you get the idea)



          var person = connection.Query<Person>("Select * FROM CUSTOMERS WHERE Id = 1").FirstOrDefault()


          NHibernate:



          var person = session.Get<Person>(Id);


          In all these instances you get back a Person class/object. Now we can encapsulate business logic (we need to have a consistent way to represent "Full Name" to our data consumers).



          public class Person
          {
          public int Id { get; set; }
          public string FirstName { get; set; }
          public string LastName { get; set; }
          public DateTime BornOn { get; set; }
          public boolean IsMarried { get; set; }
          public string FullName
          {
          get
          {
          return $"{FirstName} {LastName}";
          }
          }
          }



          but is that the main goal of it all?




          In my personal opinion, the goal of it all is to aid the developer writing good code, which includes (items relevant to the question I'll comment on);



          using the S.O.L.I.D. Principles:



          Single responsibility principle



          // What else could this class possibly be used for?
          public class Person ....


          Writing readable code with as little documentation as possible.



          var tom = dbContext.Persons.FirstOrDefault(p => p.FirstName == "Tom");

          if (tom.IsMarried) ...

          if (tom.BornOn > DateTime.Now) ...






          share|improve this answer














          share|improve this answer



          share|improve this answer








          edited Nov 14 '18 at 18:15

























          answered Nov 13 '18 at 18:53









          Erik PhilipsErik Philips

          41k691124




          41k691124













          • To add to what @Erik is saying in the last paragraph: I like using Entity Framework for working with objects.

            – MikeH
            Nov 13 '18 at 18:54








          • 1





            Ty for this answer as well. Sensible response. I think the below post works better in this case. But understand what you are saying. I have marked an answer, but feel free to post any small samples, I am sure others wonder this as well.

            – CMR
            Nov 13 '18 at 20:04













          • Yeah mark whatever answer works for you :)

            – Erik Philips
            Nov 13 '18 at 20:51











          • @ErikPhilips gorgeous example. Thank you for editing that. I think for the most part I follow what is going on here. So then from a comparison standpoint, is your example for readability and following OOP practices? Like when you show accessing from the data table, I can quickly see how much more ugly and confusing that looks versus the thought out approach, but is that the main goal of it all?

            – CMR
            Nov 14 '18 at 15:06











          • Lightly updated my answer based on your question.

            – Erik Philips
            Nov 14 '18 at 18:15



















          • To add to what @Erik is saying in the last paragraph: I like using Entity Framework for working with objects.

            – MikeH
            Nov 13 '18 at 18:54








          • 1





            Ty for this answer as well. Sensible response. I think the below post works better in this case. But understand what you are saying. I have marked an answer, but feel free to post any small samples, I am sure others wonder this as well.

            – CMR
            Nov 13 '18 at 20:04













          • Yeah mark whatever answer works for you :)

            – Erik Philips
            Nov 13 '18 at 20:51











          • @ErikPhilips gorgeous example. Thank you for editing that. I think for the most part I follow what is going on here. So then from a comparison standpoint, is your example for readability and following OOP practices? Like when you show accessing from the data table, I can quickly see how much more ugly and confusing that looks versus the thought out approach, but is that the main goal of it all?

            – CMR
            Nov 14 '18 at 15:06











          • Lightly updated my answer based on your question.

            – Erik Philips
            Nov 14 '18 at 18:15

















          To add to what @Erik is saying in the last paragraph: I like using Entity Framework for working with objects.

          – MikeH
          Nov 13 '18 at 18:54







          To add to what @Erik is saying in the last paragraph: I like using Entity Framework for working with objects.

          – MikeH
          Nov 13 '18 at 18:54






          1




          1





          Ty for this answer as well. Sensible response. I think the below post works better in this case. But understand what you are saying. I have marked an answer, but feel free to post any small samples, I am sure others wonder this as well.

          – CMR
          Nov 13 '18 at 20:04







          Ty for this answer as well. Sensible response. I think the below post works better in this case. But understand what you are saying. I have marked an answer, but feel free to post any small samples, I am sure others wonder this as well.

          – CMR
          Nov 13 '18 at 20:04















          Yeah mark whatever answer works for you :)

          – Erik Philips
          Nov 13 '18 at 20:51





          Yeah mark whatever answer works for you :)

          – Erik Philips
          Nov 13 '18 at 20:51













          @ErikPhilips gorgeous example. Thank you for editing that. I think for the most part I follow what is going on here. So then from a comparison standpoint, is your example for readability and following OOP practices? Like when you show accessing from the data table, I can quickly see how much more ugly and confusing that looks versus the thought out approach, but is that the main goal of it all?

          – CMR
          Nov 14 '18 at 15:06





          @ErikPhilips gorgeous example. Thank you for editing that. I think for the most part I follow what is going on here. So then from a comparison standpoint, is your example for readability and following OOP practices? Like when you show accessing from the data table, I can quickly see how much more ugly and confusing that looks versus the thought out approach, but is that the main goal of it all?

          – CMR
          Nov 14 '18 at 15:06













          Lightly updated my answer based on your question.

          – Erik Philips
          Nov 14 '18 at 18:15





          Lightly updated my answer based on your question.

          – Erik Philips
          Nov 14 '18 at 18:15













          1














          This won't answer the "what is the right way" question, but if you want to maintain readability while still using indexes you could create an enum:



          enum ColumnNames
          {
          FirstName = 1,
          LastName =2,
          }

          dt.Rows[i][(int)ColumnNames.FirstName].ToString();





          share|improve this answer
























          • Love it, using it, this is the right way lol. Best of both worlds here.

            – CMR
            Nov 13 '18 at 20:01
















          1














          This won't answer the "what is the right way" question, but if you want to maintain readability while still using indexes you could create an enum:



          enum ColumnNames
          {
          FirstName = 1,
          LastName =2,
          }

          dt.Rows[i][(int)ColumnNames.FirstName].ToString();





          share|improve this answer
























          • Love it, using it, this is the right way lol. Best of both worlds here.

            – CMR
            Nov 13 '18 at 20:01














          1












          1








          1







          This won't answer the "what is the right way" question, but if you want to maintain readability while still using indexes you could create an enum:



          enum ColumnNames
          {
          FirstName = 1,
          LastName =2,
          }

          dt.Rows[i][(int)ColumnNames.FirstName].ToString();





          share|improve this answer













          This won't answer the "what is the right way" question, but if you want to maintain readability while still using indexes you could create an enum:



          enum ColumnNames
          {
          FirstName = 1,
          LastName =2,
          }

          dt.Rows[i][(int)ColumnNames.FirstName].ToString();






          share|improve this answer












          share|improve this answer



          share|improve this answer










          answered Nov 13 '18 at 18:51









          MikeHMikeH

          3,2691028




          3,2691028













          • Love it, using it, this is the right way lol. Best of both worlds here.

            – CMR
            Nov 13 '18 at 20:01



















          • Love it, using it, this is the right way lol. Best of both worlds here.

            – CMR
            Nov 13 '18 at 20:01

















          Love it, using it, this is the right way lol. Best of both worlds here.

          – CMR
          Nov 13 '18 at 20:01





          Love it, using it, this is the right way lol. Best of both worlds here.

          – CMR
          Nov 13 '18 at 20:01


















          draft saved

          draft discarded




















































          Thanks for contributing an answer to Stack Overflow!


          • 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.




          draft saved


          draft discarded














          StackExchange.ready(
          function () {
          StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53287608%2fdata-table-retrieval-using-column-name-or-integer%23new-answer', 'question_page');
          }
          );

          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







          Popular posts from this blog

          Bressuire

          Vorschmack

          Quarantine