Am I on the right path...

[robjens]

(third and last part)

In general I have the following in mind:
Database <-> LisaDataObject <-> Business Objects <-> Controls

One would ask perhaps: why not bind data to the controls directly?

First is that I don't like the VS wizards. They create code-behind-behind and I don't want to miss important parts of code which is essential for my application. Everything is tightly packed together and allows me for maximum flexibility (I change table and columnnames in the database quite often in this stage, I know I should have this stuff sorted out already but it's hard to decide on naming conventions).

Last reason for this approach is that now I can use 2 or 3 lines of code to do a lot of work so it's clean as well.

Would this be a acceptable approach from the perspective of a .NET developer?

[Frinavale]

Oh I see you don't like the Visual Studio designer stuff.

Neither do I...it frustrates me and when people ask questions related to why their data isn't working properly because of the designer I pretty much abandon the question or try to convince them to not use it.

You can still use databinding without relying on the Visual Studio designer. Binding is extremely powerful and makes life a lot nicer....and the way things are going with WPF (etc) it seems to be the way of the future.

Take another look at databinding.


-Frinny

[robjens]

Thank you so much for sharing that Frinavale. I kinda missed that someone answered this topic so please excuse me for the delayed response.

Partially I have found the stuff I addressed, most easily being the property scoping rules of course. Though for now in my code I mostly use Private and Public (for ease of mind) but where the latter could be replaced with Protected Friend without problems.

My main problem with the VS wizards is, as you noted, indeed the code-behind-behind generated lines. It leaves traces when deleting the objects (like bs, ds, da etc) from the visual designer IDE which is just stupid regardless of simply using the error window to remove them. Something fundamental like that (MS uses a lot of these objects to do stuff) and still have these easy to spot bugs, it just doesn't make much sense. VS doesn't behave like that with other "items" on a form and I guess they would have fixed this by now. It's hard to fix no doubt.

For learning purposes and mainly because of flexibility I have set my mind on T3 program layers and came a long way in a short time. Thanks to some Bytes.com posts among others so cheers for that ;)

Furthermore, my focus on OOP business objects and LINQ has mainly to do with possible future requests from my employer. For now I'm just programming as a hobby but I'm trying to make a solid starting point for any future stuff and knowing my employer will flip-flop a lot.

The problem with implementing polymorphism or reflection is mainly due to the fact that I try to implement them on a existing concept rather than actually needing them for my business model to function. The wrong way.

Anyway thanks again for sharing your insight and time.

Best regards,

Rob

[Niheel]

Please one question per thread, this is a discussion.

[Frinavale]

I've split the thread into 3 threads.