• Visitors can check out the Forum FAQ by clicking this link. You have to register before you can post: click the REGISTER link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. View our Forum Privacy Policy.
  • Want to receive the latest contracting news and advice straight to your inbox? Sign up to the ContractorUK newsletter here. Every sign up will also be entered into a draw to WIN £100 Amazon vouchers!

.NET generated data sets annoyance

Collapse
X
  •  
  • Filter
  • Time
  • Show
Clear All
new posts

    .NET generated data sets annoyance

    Using the data set designer I have a bunch of returned fields which are read only.

    For each of these it generates a property with both a get and a set. Ok, if any attempt is made to set the property it throws a "read only" exception.

    I would prefer to be able to generate these as read only properties so my clients don't even have access to a "set" (at least on the typed row - though they could always cast it to a data row and do whatever they wanted anyway through it's columns.

    So any idea how I might achieve this ?

    [I can hypothsize as to the reason it is the way related to the point at which the typed rows are created since during initialization there has to be a set available, but this could only be achieved by having the constructor take all the fields]

    #2
    Don't use a tulipe technology (DataSets) just because it exists.

    Comment


      #3
      Originally posted by jmo21 View Post
      Don't use a tulipe technology (DataSets) just because it exists.
      Looks like your post didn't work correctly, the bit where you explain why its tulipe and what you'd recommend as an alternative seems to be missing.

      Comment


        #4
        Originally posted by jmo21 View Post
        Don't use a tulipe technology (DataSets) just because it exists.
        Of course there are alternatives. Most of which involve a lot more effort. Of course I could rewrite the entire application in order to get over this particular issue and not use datasets, but then I'd still be stuck with all the other tulipe.

        Of course I'm always happy to look at alternatives. Just point me at some.

        Comment


          #5
          Create DataViews on your dataset for consumption by your clients.

          These will be readonly.

          Comment


            #6
            Originally posted by pacharan View Post
            Create DataViews on your dataset for consumption by your clients.

            These will be readonly.
            That does provide a partial solution.

            The data view does expose an underlying table property (though I might be able to set it to null). The other issue I am having is with scoping of the data adapters. Basic idea being that if I don't expose them outside the project a badly behaved client can't wreak too much havoc, yes they can do whatever they want with the data but have no means of committing it, save through methods I provide. Problem here is I would ideally like to expose the tables - so that the typed rows etc are available to the clients, but not the adapters. Haven't found a set of modifiers that will actually let me do this at the moment though.

            Obviously actually trying to protect things is a bit iffy anyway since reflection will pretty much defeat it if somebody is determined anyway so perhaps I Shouldn't worry too much.

            I think the designer could be rather better, but it is what is is so I have to live with it.

            Cheers.

            Comment


              #7
              Dataset are fking atrocious.

              I once worked at a place on a winforms project.

              They used a datasets but instead of having one dataset to represent the database. Each page had its own dataset, which partially represented the DB, and each dataset had its own unique inline SQL command to fill them.

              Eventually the guy who designed it left, and we just used LINQ.

              By far the most painful job i've done.

              Comment


                #8
                NHibernate is a good, open source ORM (Object Relational Mapper) too - far better than EntityFramework.

                GE

                Comment


                  #9
                  Originally posted by garethevans1986 View Post
                  NHibernate is a good, open source ORM (Object Relational Mapper) too - far better than EntityFramework.

                  GE
                  And both are far far better than llbgen pro
                  merely at clientco for the entertainment

                  Comment


                    #10
                    Originally posted by Robinho View Post
                    Eventually the guy who designed it left, and we just used LINQ.

                    By far the most painful job i've done.
                    You'll be pleased to know I'm doing well in my new job as head of DataSet implementation.

                    Comment

                    Working...
                    X