none
Solution-wide Datasets in C# WinForms (.net 4.x) RRS feed

  • Question

  • I have just transformed my solution from vs2008 .net 3.5 to vs2013 .net 4.5.1. Not, as I am optimizing the whole staff, I wanna separate DataBase and the other logic to separate projects within current solution.

    I did it, named a new project DataBase and the rest project names stayed unchanged. As database project compiles like an dll, I am able to use all DataSets in all projects in this solution, BUT: when I navigate to DataSource explorer in vs2013 interface - nothing is present there - I have to manually create all datasets referencing to database project, manually create all adapters and staff to include them in windows form.... I's like a pain in the ..... 

    What I managed to do somehow was to create temporary windows form in database project, drop what i want to that for - designer creates datasets and adapters automatically, and then cut/paste them to the other project. Rough and artificial way....

    So, help needed it terms of the best practice in this situation. The goal is to have a solution-wide datasets accessible for ALL projects in natural way - through dataset explorer window in visual studio.

    Any help will be appreciated.... totally confused....
    • Moved by CoolDadTx Monday, December 29, 2014 6:10 PM ADO related
    Saturday, December 27, 2014 7:40 PM

Answers

  • You are correct in wanting to separate your DataAccess from your UI, such that you have a separate DataAccess project. May I also suggest that you need to have a separate DataSet project as well? This DataSet project can then be referenced by both DataAccess and UI projects (throw in a WebService project to be used between DataAccess and UI and everybody's happy!!)

    As I see it, it sounds like the only problem you're having is not being able to drag-and-drop your DataSources onto your Forms. That's not really all that important, is it? I like drag-and-drop for things like creating the objects on a Form, but not for databinding. It has never seemed right to me, and I have been in this business a very long time. Besides, I think this might still lead to DataAccess in the UI, which you are trying to get away from.

    I am also of the opinion (and I am not alone), that DataSets should not be tightly coupled to a database, which the use of TableAdapters leads to (since the TableAdapters get generated in the same file as the Typed DataSet). I have found that there are ways around this (but I don't know all the details for doing that). In fact, I never use TableAdapters at all, I prefer to use DataAdapters. However, if you've relied heavily on TableAdapters in your current application, it may be a lot of work to refactor to using DataAdapters instead.

    Several years ago, I wrote a few blogs on these subjects. They may be of some use to you:

    http://geek-goddess-bonnie.blogspot.com/2009/09/tableadapters-are-crap.html
    http://geek-goddess-bonnie.blogspot.com/2010/04/create-xsd.html

    And also a 3-part series about DataAccess:

    http://geek-goddess-bonnie.blogspot.com/2009/09/dataaccess-part-i.html
    http://geek-goddess-bonnie.blogspot.com/2009/10/dataaccess-part-ii.html
    http://geek-goddess-bonnie.blogspot.com/2009/10/dataaccess-part-iii.html

    Each DataAccess post adds extra complexity to the DataAccess classes, but more flexiblity. The first post is enough to get you going in the right direction and give you a general idea of the concept (but I think you already understand the part about separating DataAccess from UI), but the second post is more useful. The third post gets into using anonymous delegates (which were useful in a Framework I developed at another company I worked for, but I no longer use anonymous delegates for my current DataAccess work).

    I hope that helps some ...


    ~~Bonnie DeWitt [C# MVP]

    http://geek-goddess-bonnie.blogspot.com

    • Marked as answer by Romiko GNCC Tuesday, December 30, 2014 6:10 AM
    Tuesday, December 30, 2014 5:58 AM

All replies

  • Hi Romiko,

    As far as I know, I think the dataset could not work for all projects in the design view.

    In an alternative way, I think you could try to use the dataset with the ado.net.The link below show how to transfer dataset files to another project.

    # How to transfer my whole dataSet files to another project ?
    https://social.msdn.microsoft.com/Forums/vstudio/en-US/4c1e44fb-10ab-455b-b3f3-70e332944363/how-to-transfer-my-whole-dataset-files-to-another-project-?forum=csharpgeneral

    Best Regards,

    Edward


    We are trying to better understand customer views on social support experience, so your participation in this interview project would be greatly appreciated if you have time. Thanks for helping make community forums a great place. <br/> Click <a href="http://support.microsoft.com/common/survey.aspx?showpage=1&scid=sw%3Ben%3B3559&theme=tech"> HERE</a> to participate the survey.


    Monday, December 29, 2014 9:57 AM
  • Hello,

    Since you are revamping your solution please consider looking at Entity Framework where you can create everything in a class project then use this functionality in your forms projects. It will take sometime to get use to Entity Framework but is well worth the effort.



    Please remember to mark the replies as answers if they help and unmark them if they provide no help, this will help others who are looking for solutions to the same or similar problem.

    Monday, December 29, 2014 1:58 PM
  • You are correct in wanting to separate your DataAccess from your UI, such that you have a separate DataAccess project. May I also suggest that you need to have a separate DataSet project as well? This DataSet project can then be referenced by both DataAccess and UI projects (throw in a WebService project to be used between DataAccess and UI and everybody's happy!!)

    As I see it, it sounds like the only problem you're having is not being able to drag-and-drop your DataSources onto your Forms. That's not really all that important, is it? I like drag-and-drop for things like creating the objects on a Form, but not for databinding. It has never seemed right to me, and I have been in this business a very long time. Besides, I think this might still lead to DataAccess in the UI, which you are trying to get away from.

    I am also of the opinion (and I am not alone), that DataSets should not be tightly coupled to a database, which the use of TableAdapters leads to (since the TableAdapters get generated in the same file as the Typed DataSet). I have found that there are ways around this (but I don't know all the details for doing that). In fact, I never use TableAdapters at all, I prefer to use DataAdapters. However, if you've relied heavily on TableAdapters in your current application, it may be a lot of work to refactor to using DataAdapters instead.

    Several years ago, I wrote a few blogs on these subjects. They may be of some use to you:

    http://geek-goddess-bonnie.blogspot.com/2009/09/tableadapters-are-crap.html
    http://geek-goddess-bonnie.blogspot.com/2010/04/create-xsd.html

    And also a 3-part series about DataAccess:

    http://geek-goddess-bonnie.blogspot.com/2009/09/dataaccess-part-i.html
    http://geek-goddess-bonnie.blogspot.com/2009/10/dataaccess-part-ii.html
    http://geek-goddess-bonnie.blogspot.com/2009/10/dataaccess-part-iii.html

    Each DataAccess post adds extra complexity to the DataAccess classes, but more flexiblity. The first post is enough to get you going in the right direction and give you a general idea of the concept (but I think you already understand the part about separating DataAccess from UI), but the second post is more useful. The third post gets into using anonymous delegates (which were useful in a Framework I developed at another company I worked for, but I no longer use anonymous delegates for my current DataAccess work).

    I hope that helps some ...


    ~~Bonnie DeWitt [C# MVP]

    http://geek-goddess-bonnie.blogspot.com

    • Marked as answer by Romiko GNCC Tuesday, December 30, 2014 6:10 AM
    Tuesday, December 30, 2014 5:58 AM
  • Thank you so much for the answer, will try to and get an update on my progress.
    Tuesday, December 30, 2014 6:10 AM
  • You're welcome! Glad I could help!  =0)

    Oh, one more thing ... if you use LINQ queries on your DataTables, and you *are* planning to do away with the TableAdapters, then you might want to read another blog post of mine:

    http://geek-goddess-bonnie.blogspot.com/2012/08/msdatasetgenerator-gone-wild.html

    In addition, I've found a link that shows how to separate TableAdapter generation from DataSet generation (placing the two sets of generated code in different projects). I still find TableAdapters less than ideal, but you should have the option of doing this if you're interested: http://msdn.microsoft.com/en-us/library/bb384586(v=vs.120).aspx


    ~~Bonnie DeWitt [C# MVP]

    http://geek-goddess-bonnie.blogspot.com

    Tuesday, December 30, 2014 4:31 PM