OO design and programming...

  • Thread starter Thread starter Brad Pears
  • Start date Start date
B

Brad Pears

I am completely new to vb .net. I am using visual Studio 2005 to redo an
Access 2000 application into a .net OO application using SQL Server 2000 -
so a complete rewrite and re-thinking of how this app will work.

I have NEVER done any OO programming at all although I have used OO
techniques in programs of course - just never actually designed the classes
etc...

So I am just a tad nervous in re-writing this Access application as it is a
large app and I am learning so many new things I have never used before such
as vb.net, OO design, SQL server and Crystal!!! It is a little mind boggling
to be doing a big project using all this new stuff!!!

Right now I figured the best place to start was to look at the existing
application and try to extract from that what some of my classes will be for
the new app and then add new classes. Then from that I can determine the
data required and methods for each class - which will then lead to the
physical SQL Server db design to facilitate my class design. The physical db
will be WAY different than the old Access 2000 design.

I guess I am looking for a little guidance from those who work in this all
the time. Am I doing this in the right order basically ?

I am also looking for a really god book on OO design principals - leaning
towards vb.net would be good but the principals are all the same so just an
overall OO design book would be good.

Does any one know of a good one - or some really good reference material for
this on the internet? I am unsure of things like how many classes do I
really need to mimic a parent child relationship for instance. The parent
would be one class and the children would be yet another class - but would
it be a subclass of the parent etc.. etc.. Figuring out how many classes
and their relationships - when to create new classes or include all the data
in one class is what I am having a hard time with. (when to subclass and
when not to...)

Any help at all would be most appreciated!!!

Thanks, Brad
 
You should design the data structures first, which leads
to your business layer classes, and then the UI.

To quote myself, I just posted the following recommendation
to someone else:

Deborah Kurata has a book coming out in January called "Doing Objects
in VB2005". It explains the GUIDS methodology for analysis and
design, and then shows you explicitly how to set up your 3 layers.
You end up writing an entire application. I found the book clear
and concise, and a lot easier than reading an entire book on theory.
It also had a lot of neat things in it about saving your project
settings, code snippets, and bet of all, binding your data to objects.

Rockford Lhotka also has some business objects books that are
supposed to be definitive.

Robin S.
--------------------------------
 
How did you manage to see this book ahead of time?? Any chance of getting it
early?? I am starting this now and would be nice to have a good reference
handy...

Thanks for the help.
 
I knew Deborah because she's the head of my local .Net User Group.
I had some extra time, and knew she was working on her book, so
I offered to read it for content and work through all the example
work. It was a great opportunity for both of us. :-D So I'm
sorry, but it's not going to be available until January. It
does sound like exactly what you need. It really brought everything
together for me, and was the foundation for me making the jump from
VB6 to VB.Net. It explained classes and inheritance and objects.
Reading it made it easier for me to understand everything else
I read after that.

On the bright side, January is not very far away?

If you're desperate, you could check out her VB6 for Objects book;
it's available on amazon for like 67 cents. It's in the wrong
version of the language, but you'd get the general idea. That
version has a lot more information on the analysis/design stage,
from what I understand.

If I hear anything about it coming out sooner, or if I can
get my hands on an advance copy, I'll let you know next week.

Robin S.
--------------------------
 
I think C# is a more intuitive OO language. I will suggest you start
with it instead of VB.
 
I think C# is a more intuitive OO language. I will suggest you start
with it instead of VB.
 
I think C# is a more intuitive OO language. I will suggest you start
with it instead of VB.
 
My creds -- I led a project to convert the largest ever Access application
to .Net; I know both Deborah and Rocky and respect their talents...

First, I feel your pain!

Second, question the move at all. Access is not going away soon. I'll
assume you have done so and decided it is necessary.

Third, do not let your management underestimate the magnitude of the task (I
don't think _you_ are). If the Access app is indeed very large, you are in
for a ride. We spent well over $2MM to convert our app.

If you was me, I'd take RobinS' advice, in a way. I'd glom onto to Rocky's
framework and use it as the basis of your redesign. I don't know it
intimately, but I know that Rocky is one smart guy. So you get his wisdom --
and framework -- for the price of a book (actually the framework is
down-loadable for free from his website).

Next, I'd get some VB.Net mentoring. Nothing intensive, but a couple of
days would save you a couple of months if someone walked you through
VisualStudio (2005) and the basics of VB.Net and the .Net framework. You'll
be amazed at how much you already know -- and can discover via
intellisense--, but there is a paradigm shift and once you grok it you are
on your way. There is a ton of info on MSDN and GotDotNet -- so much so
that it is overwhelming at first.

I would suggest that you do accept the fact that you need to rewrite the app
and forget about any magical translation. And don't look back.

Good luck!

HTH,

Prester John

P.S. I don't frequent the discussion groups very often -- email me, if you
want to, at (e-mail address removed)
 
I second this. VB is easier on the fingers syntactically and is quite
similar to VB 6/VB Script. I would definately take RobinS recommendation
though but especially make sure those you are working for understand what a
big change it is. Sometimes managers see the words "Upgrade Wizard" and
assume this kind of job is a simple button click away from completion.
Sometimes it's actually quicker to re-write the application from the
ground-up than to fiddle around with existing code.

Also remember what Prester John said: question the need to upgrade in the
first place.
 
Thomas,

Do you know both languages.

VB.Net is in my idea definetly more OOP than C#.

Cor
 
Thanks John. I really appreciate your advice (as I also said to Robin!). I
will follow it!

You have both been very helpful.

PS.. Yes, the decision was made to move everything over to SQL Server and to
standardize on vb .net apps. We don't have a whole lot of stuff left in
Access so better to do it now than continue to write more in Access and
convert later.

PSS.. What is the specific book name by Rocky that you refer to??

Brad
 
RobinS said:
On the bright side, January is not very far away?
Click to expand...

A little farther away than expected. Amazon shows that that book will
not be published until March 27, 2007!! :(

It does sound like a nice book, though.

Chris
 
OO is _WORTHLESS_

concentrate on a good client-server design on don't listen to the
con-artists that want to sell you on OOP
 
the largest Access app ever??

you should have just used Access Data Projects; I probably could have
made your project _MORE_SCALABLE_ for a measly 100k

Larry Linson Jr
ADP Nationalist
 
you just should use Access Data Projects; it is a much much simpler
environment and much much more productive than VB.net

-Aaron
 
you just should use Access Data Projects; it is a much much simpler
environment and much much more productive than VB.net

-Larry Linson Jr
ADP Nationalist
 
Thomas

EAT A DICK ****ER

we're in a VB 2005 newsgroup; so you should go and sell your wares
elsewhere

-Larry Linson Jr
 
Back
Top