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

You are not logged in or you do not have permission to access this page. This could be due to one of several reasons:

  • You are not logged in. If you are already registered, fill in the form below to log in, or follow the "Sign Up" link to register a new account.
  • You may not have sufficient privileges to access this page. Are you trying to edit someone else's post, access administrative features or some other privileged system?
  • If you are trying to post, the administrator may have disabled your account, or it may be awaiting activation.

Previously on ".NET generated data sets annoyance"

Collapse

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

    Leave a comment:


  • eek
    replied
    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

    Leave a comment:


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

    GE

    Leave a comment:


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

    Leave a comment:


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

    Leave a comment:


  • pacharan
    replied
    Create DataViews on your dataset for consumption by your clients.

    These will be readonly.

    Leave a comment:


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

    Leave a comment:


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

    Leave a comment:


  • jmo21
    replied
    Don't use a tulipe technology (DataSets) just because it exists.

    Leave a comment:


  • ASB
    started a topic .NET generated data sets annoyance

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

Working...
X