Some advice need regarding good practices

[schoemr]

Have you ever program yourself in circles? Click this then that button must be disable, and open that form then this textbox color must be red etc. etc. until eventually you are back to where you started but nothing is work properly.

It is sometime very frustrating..

Also, my queries in the .xsd so so many, it looks like a spiderweb x 1000 it is getting more hard to find what I am looking for. I have try to organize all table adapers but it is more hard work to keep some "organized system" in there...

How do you organize all your adapters? And how do you prevent going around in circles with writing code?

[ident]

I can't think of an instance. I'm not on an hourly rate so I have the luxury of taking my time to organize all my classes with good documentation. I program for myself strictly as a hobby, however, I will still design flowcharts etc. If you are running ahead of your logic and flow then that's asking for trouble. I follow my own rules and don't worry about rolling out a class with only a few lines. To me, the organization is better than crammed noisy classes. Ten years ago a member here taught me noise is bad. I could not agree more now.

It's hard to answer because you have not provided an example.

[wes4dbt]

Yeah, a screen shot of the Typed Dataset that you feel is unorganized, showing as many DataTables and TableAdapters as possible would make it a lot easier to give advise.

[jmcilhinney]

How do you organize all your adapters?

Generally, you start with one DataTable/table adapter per database table, so there's no issue there. If you add queries to those table adapters then you are also adding methods and if those methods are well-named then they are self-documenting. For instance, if you have a Thing table then it has a default query that is executed via Fill and GetData methods. If you wanted to be able to retrieve only Thing records with a specific StuffId then you add a query with an appropriate WHERE clause and it gets executed via FillByStuffId and GetDataByStuffId methods.

There's nothing there that should be confusing at all. One thing that can cause issues is that people feel like they need use method names that are as short as possible. In the age of Intellisense, don't fall into that trap. If you need to use a long name to make it clear what a method does then do so. You'll never have to type the whole thing out so don't make your code harder to understand to save yourself a few keystrokes that you'll never have to actually make anyway. If you are filtering by StuffId, OtherStuffId and MoreStuffId then name your methods FillByStuffIdOtherStuffIdMoreStuffId and GetDataByStuffIdOtherStuffIdMoreStuffId. The idea that long method names are bad is just wrong. Short method names that don't tell you what the method does is bad.

You only ever really need to add a new DataTable/table adapter if you need a specific combination or subset of data that doesn't correspond directly to a table. If you create such a DataTable then name it appropriately. Again, if the name needs to be long then make it long. Basically, your whole DataSet should be self-documenting so, if you're having trouble finding what's what, it's because you have used poor names.

And how do you prevent going around in circles with writing code?

I think that the most important factor here is the principle of Divide & Conquer. If you find yourself going round in circles it is often because you're actually trying to solve multiple related problems at the same time. What you really need to do is break the initial problem up into the smallest constituent parts that you can and then solve each part independently. Conceptually, what you want to do is to break your process up into black boxes, where each black box is a basic unit of functionality. You should be able to work on each black box independently because its functionality is independent of all the others. Each box will have pipes going in (data inputs) and pipes going out (data outputs). You should be able to break things down to such a degree that each box has one pipe going in and one pipe going out. If you find that a box has multiple pipes going in one direction or the other then you can almost certainly break that box up into smaller boxes that each have just one pipe in and one pipe out.

Once you have all your boxes, you can work on the internals of one box at a time, in complete isolation. You can test it with predefined inputs that you choose rather than their being dependent on the rest of the application. You provide an input, debug the code and check that the output is what you expect. When that's done successfully for a reasonable range of inputs, you can consider that box to be complete and put it aside. Using this methodology, you might have a process that has ten steps and you can complete steps in the middle first without issue. The preceding steps don't have to have been completed because all a box cares about is the input it gets, not where that input came form or how it was generated.

You can, in theory, complete all your boxes in complete isolation and then simply plumb them together at the end. This is basically how teams of developers work. A software architect does will basically determine what the boxes are and then multiple developers will work on separate boxes, possibly completely independently. Someone is then responsible for making sure that the boxes work together as expected. If they have been defined well and created properly, they should all just click together.

You'll also find that larger projects will make copious use of interfaces to facilitate this process. For instance, let's say that you have box A and it needs to make use of the output of box B. In the final application, they will correspond to classes BoxA and BoxB where BoxA needs to call Method1 of BoxB. When we start out - and for our entire career in many cases - we think that we have to write BoxB and Method1 first, before we can start writing BoxA. In many cases, that's just not practical. To allow BoxA to be written at the same time as BoxB or even before, an interface IBoxB with Method1 can be defined. Now, instead of referring to the BoxB class directly, BoxA will refer to the IBoxB inreface. Now, the developer working on BoxA can write all the code they want against the IBoxB interface even if the BoxB class doesn't exist yet. To test, they can use any type that implements IBoxB. They could write their own basic class where Method1 just returns a hard-coded value if they wanted. What generally happens in bigger projects is that they use an Inversion of Control (IoC) container. Basically that is a library that will give you an object that implements the interface you specify. That way, you can configure the IoC container to give you a mock object for unit testing or a any type you want that implements the specified interface. You don't need to configure it to return a BoxB instance until that BoxB class is ready to use.

So, my short answers are use good names that are self-documenting and Divide & Conquer.

[schoemr]

Hi John,

Thank you very much for such well explained answer. I have to read it more times...

Here is small segment of the dataset, if I scroll to right hand side there is much more. Maybe 10x more...

Attachment 159701

[FunkyDexter]

I haven't looked closely at your diagram but I think the complexity you're seeing is a reflection of the complexity of the underlying database structure. Would I be right in saying that you basically have one table adapter per database table, much as JM suggested in the first sentence of his last post? If so, don't panic, this is normal.

When we teach databases we tend to use simple examples. Customers have Orders... Orders are made up of Items... Woot! I've got an application. The real world's not like that. The real world's complex. Having lots of inter-related tables, each with a few columns, is a good sign. If you've got a few very wide tables that's probably an indicator that you haven't normalised properly. The downside is that it produces really scary looking diagrams.

The trick when managing this is similar to the trick Jm described when managing methods: Divide and Conquer. Never try and look at the whole structure at once - it'll just terrify you. Instead just look at the bit you're focussed on right now. Working on the customer ordering functionality? Don't bother calling up the details of the Staff payroll scheme. If you can define a few diagrams that focus on particular areas (Does Visual Studio allow that? I can't remember. Management Studio certainly does) it really helps.

[jmcilhinney]

The downside is that it produces really scary looking diagrams.

Quite so. In my office, we use Entity Framework rather than typed DataSets but here's a look at the model diagram for a recently released application. I've scaled the diagram to fit every entity in.



The thing is, we rarely actually use the diagram anyway. We're usually working with types in code, so there's little need to care if there are lots of types in the Intellisense list. If we do ever need to visualise some part of the model using the diagram, it is generally just some part, as FD suggested. In that case, we can drag just the entities we're interested in to a free area and concentrate just on them without the distraction of all the other entities. One good thing about the EF designer is that you can have the diagram automatically laid out after messing with it. I'm not sure whether the DataSet designer offers that, which may help lead to the feeling that your diagram is a mess. Like I said though, there should not really be all that much reason to refer to the diagram most of the time.

[NeedSomeAnswers]

Have you ever program yourself in circles? Click this then that button must be disable, and open that form then this textbox color must be red etc. etc. until eventually you are back to where you started but nothing is work properly.

The others have spoken quite a bit about data-sets so i am going to address your other issues;

Firstly rules based actions.

It sounds like you have different rules which mean different actions happen, for instance buttons are enabled or disabled, and what a lot of people get into the habit of here is just adding that rule as part of another sub or method.

So you have a method that gets data and if one of the fields it gets for instance is a Boolean and it returns false then you check it in the Get data sub and then set your button disabled there and then.

Dont do this !!!

Instead group your rules in there own sub and give it a nice name such EnableAdminFunctions, and in that function do all the rules actions that are required for that action.

You can also have a corresponding sub called DisableAdminFunctions. This makes it very simple to see in your code what is happening where.

Its the same for buttons, i have seen a lot of application that have 2 or 3 menus / buttons which do the same action like a save, and yet they add the save code directly in the button click for each button / menu so they basically have the same or similar code in there 3 times. They get asked to make a change to the save, forget to change one of the 3 save routines and things stop working as expected.

Never put your code directly in the button click even if right now your only calling it once, it will get you into good habits and if you then do need to call the same code from somewhere else you just call the existing sub.

Lastly i am going to re-iterate what JMC said on naming here is an example form an actual application of mine. This is the load method of a form -

Private Sub FrmQuestionnaireEdit_Load(ByVal sender As Object, ByVal e As EventArgs)
    GetQuestionTypes()
    GetLookups()
    GetCaseTypes()
    GetQuestionnaireData()
    LoadQuestionnaire()
End Sub

Each on of the methods that starts with Get, gets data.

The LoadQuestionnaire method then loads data into the form.

This not only keeps things simple to read, that fact that i use the prefix Get to mean getting data on ALL my subs means straight away looking at them i know what they do.