Big Desktop Database Application - Architecture Help needed [modified]
-
Hello, I am designing a .NET database application that uses 3 tier architecture. Starting initially, this application will be desktop application but I will convert it into a website later but design that I am planning should support both version. Development Environment : VS2008 Currently Database supported are MS SQL Server 2005 and MYSQL 5 and design for database support is extensible. This application contains several high level modules (HLM) that can either share the data from the database of other high modules and some are totally independent modules. Like say finance and project automation are not dependent on each other but finance and investments are. These are some examples of the modules that will be used in this the application. For website version of this app, Main Website will mainapplication.com and High level module (HLM) will be having subdomain names like hlm1.mainapplication.com , hlm2.mainapplication.com and so on. Database Name : mainapplication Now for desktop version should I create different EXE application and linked them to the main application and share the same database with all the apps? I like the design of MS Money application for desktop application. However, this is only a finance application and it is also that big. Can that design help me for this scenario or are there any references of big desktop application that is extensible and contains support for database ? Currently I have research enough on desktop application for 1. Interprocess communication can be using named pipes, since it is on same machine. 2. Single Sign on in main application will allow access to other HLM exe application. 3. Only Main application will call the other HLM application. Running HLM Exe alone will give a error . 4. New HLM application will have a module code and store in the database and loaded in the main application once logged in. Using module code, the HLM exe will be loaded. 5. Main application will have framework to support dynamic linking of HLM and have base libaries that will be implemented and use by HLM exe application. 6. Each HLM exe will have its seperate BO and DAO layers. 7. If HLM B depends on HLM A then HLM B will reference HLM A BO layer for calling functionalities that are required. 8. There will be only 1 instance of the any application running at anytime time. I am not sure of the following 1. Transaction handling between multiple processes. 2. If there are anything else that I need to
-
Hello, I am designing a .NET database application that uses 3 tier architecture. Starting initially, this application will be desktop application but I will convert it into a website later but design that I am planning should support both version. Development Environment : VS2008 Currently Database supported are MS SQL Server 2005 and MYSQL 5 and design for database support is extensible. This application contains several high level modules (HLM) that can either share the data from the database of other high modules and some are totally independent modules. Like say finance and project automation are not dependent on each other but finance and investments are. These are some examples of the modules that will be used in this the application. For website version of this app, Main Website will mainapplication.com and High level module (HLM) will be having subdomain names like hlm1.mainapplication.com , hlm2.mainapplication.com and so on. Database Name : mainapplication Now for desktop version should I create different EXE application and linked them to the main application and share the same database with all the apps? I like the design of MS Money application for desktop application. However, this is only a finance application and it is also that big. Can that design help me for this scenario or are there any references of big desktop application that is extensible and contains support for database ? Currently I have research enough on desktop application for 1. Interprocess communication can be using named pipes, since it is on same machine. 2. Single Sign on in main application will allow access to other HLM exe application. 3. Only Main application will call the other HLM application. Running HLM Exe alone will give a error . 4. New HLM application will have a module code and store in the database and loaded in the main application once logged in. Using module code, the HLM exe will be loaded. 5. Main application will have framework to support dynamic linking of HLM and have base libaries that will be implemented and use by HLM exe application. 6. Each HLM exe will have its seperate BO and DAO layers. 7. If HLM B depends on HLM A then HLM B will reference HLM A BO layer for calling functionalities that are required. 8. There will be only 1 instance of the any application running at anytime time. I am not sure of the following 1. Transaction handling between multiple processes. 2. If there are anything else that I need to
abhijitbkulkarni wrote:
This will be big application should the design and architecture should be finalize first
I'm pleased to hear it, but this should really be the case with just about any project. Can I suggest that you take a look at Microsoft's Composite Application Block? This will help clarify a lot of the problems/issues you may encounter, and is a good place to start when thinking about a decoupled architecture - especially when the interface can vary so widely.
Deja View - the feeling that you've seen this post before.
-
abhijitbkulkarni wrote:
This will be big application should the design and architecture should be finalize first
I'm pleased to hear it, but this should really be the case with just about any project. Can I suggest that you take a look at Microsoft's Composite Application Block? This will help clarify a lot of the problems/issues you may encounter, and is a good place to start when thinking about a decoupled architecture - especially when the interface can vary so widely.
Deja View - the feeling that you've seen this post before.
That surely help. It gave me a starting point for what I required. I will go through Composite Application Block and check with the design that will be best for the application. Thanks for reply.
-
abhijitbkulkarni wrote:
This will be big application should the design and architecture should be finalize first
I'm pleased to hear it, but this should really be the case with just about any project. Can I suggest that you take a look at Microsoft's Composite Application Block? This will help clarify a lot of the problems/issues you may encounter, and is a good place to start when thinking about a decoupled architecture - especially when the interface can vary so widely.
Deja View - the feeling that you've seen this post before.
Pete O'Hanlon wrote:
Microsoft's Composite Application Block
Looks interesting enough :)
"The clue train passed his station without stopping." - John Simmons / outlaw programmer "Real programmers just throw a bunch of 1s and 0s at the computer to see what sticks" - Pete O'Hanlon