For questions 1 and 2 go with Matthew's answers.
I have spent a great deal of time trying to figure out the best way to structure the DAL of desktop applications. And the best way really depends on the needs of the application. In one of my apps I went down the road of having a DA class for each database table, which registered itself with a central (i.e. singleton) DataProvider class and handled the CRUD. Each DA class could then decide whether it wanted to cache all the table data in RAM or not (performance!) and/or whether it needed to have the ability to trigger automatic client updates in other clients running on other computers (think multi-user concurrency). This makes it very easy to add new DAL classes, as all they have to do is conform to the registration interface.
Not every DAL needs this kind of functionality, but I did learn that the approach itself (i.e. singleton data provider and simple DAL classes with static registration) made my life a lot easier when I started adding new classes.
I would definitely not recommend building the CRUD into higher level classes, unless this is a very simple application. The DAL is an abstraction of the data storage. If you decide to change your data storage at some point in the future (even if it is only to use MySQL instead of MS SQL), you will be very thankful for that. Plus: BLL objects should be structured by their business logic relationships. DAL objects are structured by the types of storage containers they represent. The differences can be dramatic.
Do NOT make your DAL classes static. What you gain in coding speed you will lose many times over in testability and flexibility.