A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.
I am planning 2 build a VB.Net Application with 3 modules:
1. Salesforce Automation: contacts, quotes, order
2. Billing: Billing profile, invoice, payment
3. P.O.S.: Retail Point-of-Sales
I plan to sell to the application.
1. Would it be good practice to create each module as a separate project in a solution?
2. Make each project a class library compile to a .dll
3. Is it okay to have the same vb form (ie Company or Person form) and code in each compiled class library so if i need to customize the class for one module i can do it without affecting the other?
4. Is it okay to have a separate class library for constants, utilities, database access, web services or msmq messaging and integration?
I plan to have a 4-tier architect using remoting with the goal to be able to support 2,000 users..
I am interested in alittle guidance in developing commercial software to ensure upgrading, scalability and integration..
tnx very much!
"I plan to have a 4-tier architect using remoting with the goal to be able to support 2,000 users.."
Do you mean, you plan to sell this to large organizations that may have up to 2,000 employees each using the software, or you plan to sell this to one customer with 2,000 employees, or you plan to sell 2,000 copies of your software?
As far as your first question, I'd suggest you break your product into three modules along the lines you've indicated. Sales force management, back office, and P.O.S. are very different functions and while they do overlap, there is lots of functionality in each of these that does not. What I'm saying is that you could potentially have four products here:
1. Sales force automation product.
2. Back-office product.
3. P.O.S. product.
4. Integrate the three above into an integrated suite of apps for whole-business management.
However, you need to know that you have a hell of a lot of competition starting at about $100 per user. You are entering a saturated market with what sounds like very little software development experience. Think well on what unique expertise, specific industry knowledge, or whatever you can add to a crowded market. Otherwise, you will spend a lot of time, money and effort developing a product that may not sell.
Thanks for your response.
Yes these could be standalone applications. But I plan to make it into a suite, i.e. Single User Interface to all three modules (Applications). I want the application to be able to support up to 2,000 users (i.e. performance & scalability).
I am just curious about design approaches in Visual Basic.Net verses Java Web Development. I am new to developing commercial applications in Visual Basic and so I just wanted to see if some approaches I was thinking was on the right track. That's all..
The issue is not a matter of the market being saturated the issue is in the strategy and the product. I am just using what I said as an example, do you really think I would actually share what I am going to build on a public web forum with experienced ISV's ;-)
I have access to many avenues of developer resources locally and off-shore....Don't be so quick to judge based on a few questions.
I was looking for just a response from an experienced developer regarding basic design approaches to see if what i was thinking was in the right direction...
thanks for your feedback ;-)
Thanks for the info and great idea the product will be used outside the U.S.
1. What would be the best approach to integrate the 3 projects into a product suite that uses one interface to access all 3 application modules?
2. Would it be a good ideal to run each application with it's own EXE and supporting dll's then have a main exe that provides the integrated user interface for all 3 products?
I generally go with a large, monolithic .EXE that contains all functionality, and various modules/features are enabled/disabled as needed (or "as paid for" -- you don't want to enable someting and not collect the check <grin>).
For me, it's just easier this way. To each his own, YMMV and all that.
Monday, June 12, 2006
This topic is archived. No further replies will be accepted.Other recent topics
Powered by FogBugz