Developing an Application with Multiple Modules

[Ivan Weiss]

I want to start an application for my firm (a foodservice design
consulting firm). I am doing this part time at night so it will take
awhile.

I am thinking the best approach is to develop in a series of modules so
that I can finish one, go live with it and continue to add features and
modules one by one to build on the application.

My question is how to organize a module style application, I have never
done that before....

I am assuming I would create a solution with a separate project for each
module... And I am assuming another project for the main interface.

Or am I overthinking this and should I just create the various classes
for all of the business objects and work in a UI project and access the
classes as I create them?

I have also always been very confused about how to create an
installation package when it comes down to it. I am expecting to
develop in Visual Studio 2008

-Ivan

 

[Joe Cool]

I want to start an application for my firm (a foodservice design
consulting firm).  I am doing this part time at night so it will take
awhile.

I am thinking the best approach is to develop in a series of modules so
that I can finish one, go live with it and continue to add features and
modules one by one to build on the application.

My question is how to organize a module style application, I have never
done that before....

I am assuming I would create a solution with a separate project for each
module...  And I am assuming another project for the main interface.

Exactly. You don't really need an interface. I have been told it makes
unit testing easier but no one has shown me how it really helps.

You'll probably also want to include a Class Library (or more) to
provide shared classes and code for the projects in the solution.

Or am I overthinking this and should I just create the various classes
for all of the business objects and work in a UI project and access the
classes as I create them?

If each module is in the slightest bit complex, it would be best to
put it in it's own project.

I have also always been very confused about how to create an
installation package when it comes down to it.  I am expecting to
develop in Visual Studio 2008

Just create a Setup and Deployment project in the solution. They are
pretty easy to set up but relatively limited in scope compared to a
commercial product like WISE. But are adequate for a lot of solutions.

 

[Ivan Weiss]

Thanks for the response.

So to summarize and make sure I am on the same page...

I should create a separate project for each module. In my case for
example:

Empployees
Projects
Proposals and Contracts
Billing
etc...

Each would have its own interface within that project?

Now the application I think should be a mdi style ui I believe. Where
would I put the main form that gives access to all of the modules?
Would that be a separate project called WinUI for example? And that
would call the forms within each subsequent module?

On to the deployment, I forgot to add the end of my statement. My
concern is not really with the application. But deploying the sql
database. And as I upgrade the application, updating the tables on my
live server. Is there an automated way to do that or do I need to
manually match the database to my development every deployment?

Thanks again!

-Ivan

 

[Joe Cool]

Thanks for the response.

So to summarize and make sure I am on the same page...

I should create a separate project for each module.  In my case for
example:

Empployees
Projects
Proposals and Contracts
Billing
etc...

Well, actually, it depends on the ocmplexity of the modules. If each
moduke is going to need several different forms and several different
classes to support the forms, then, yes definitely, a separate project
for each one. And make sure you reference them from the main UI
project with Project references, not browsed references.

But you later mention MDI app. That implies each module would be
represented by a single MNDI child form. If that is the case, then you
may want to consider just combining them all in with the main UI
project. YOu don't want to make things too complicated if you don't
need to.

Each would have its own interface within that project?

As I mentioned earlier interfaces aren't really necessary, it is your
call, But if you do go with separate projects for each module and you
want to go with interfaces, then yes, a separate interface project for
each module project would be the way to go.

Now the application I think should be a mdi style ui I believe.  Where
would I put the main form that gives access to all of the modules?
Would that be a separate project called WinUI for example?  And that
would call the forms within each subsequent module?

Whether you go with MDI or not, you're gonna ned a UI. Whether the
child forms are in the same project as the UI depends on the decision
I mentioned earlier that you need to make.

On to the deployment, I forgot to add the end of my statement.  My
concern is not really with the application.  But deploying the sql
database.  And as I upgrade the application, updating the tables on my
live server.  Is there an automated way to do that or do I need to
manually match the database to my development every deployment?

Ah, now you mention it is SQL based also. Don't remember you
mentioning that in your OP. That really makes things way more complex,
ESP{ECIALLY for deployemnt in stages, and later upgrades to existing
modules.

The way we do that were I work is we have a separate UI app for
administrative purposes, setting module/user properties that are
stored in the database, and a Client UI. The admin app also contains
code to create a database for initial use and to update the database
as needed, adding new tables, adding/remove new/obsolete columns, etc.
In that regard, best to have a special control table that defines the
current version level of the database. The admin app at startup would
check this level and perform an upgrade as needed. The client should
also check this version level and not let the user even startup the
client if the database version does not match the current client
version.

Thanks again!

NP.

HTH.

My only last comment would be, I would recommend C# instead of VB. I
have used both extensively and I think C# works better in the
whole .NET world.

 

[Ivan Weiss]

Based on this I think I am going to move my UI to a web interface.
After some thought it will be easier on deployment. The only thing I
will need to do is manipulate the table through the sql management suite
to modify per my new web app code. This will remove a lot of
"versioning" potential issues plus although access when remote from the
office (through vpn so security is not as big of an issue).

It also sounds like to simplify things I might be better off just making
a project for my business objects and separating each module into a
separate class and keep all of them together.

-Ivan

 

[sloan]

You can take a peek here:
http://sholliday.spaces.live.com/Blog/cns!A68482B9628A842A!140.entry

This is a layered application.

Putting your business objects in a seperate library is a good idea.
Just take a look at the sample to further seperate the "areas of concern".

 

[Cor Ligthert[MVP]]

Ivan,

Stop thinking from the way of the user interface, in your part of this
discussion I see that is the first point from where you are thinking from

Also try to avoid to use the word "module" because that has a different
meaning in VB then the way you use it, I think most wont even recognize it
anymore, it was somehow a failed approach.

However, you can reach your goal by thinking from what has to be solved.
Design for that (first logical) the Class Libraries (DLL's) don't think
about the User Interface, that can be done later. And what it than will be
is less important.

Success,

Cor