Architecture
-
Hi, We are in the process of building a new enterprise application, that would comprise of an Oracle database, and a VB.NET application. Now my request to you all is to suggest the optimal architecture, in terms of technology, stability, maintenance, etc, bearing in mind that we would like to have a multi-tier application, with a thin client, and 1 to n business/persistence layers. The application would be used by users who might be geographically separated. Would appreciate your inputs on: Winforms Vs ASP.NET? Communication, Data persistence, Performance, Any other criterion that you might consider important. Your inputs would be highly appreciated. Cheers/RB
-
Hi, We are in the process of building a new enterprise application, that would comprise of an Oracle database, and a VB.NET application. Now my request to you all is to suggest the optimal architecture, in terms of technology, stability, maintenance, etc, bearing in mind that we would like to have a multi-tier application, with a thin client, and 1 to n business/persistence layers. The application would be used by users who might be geographically separated. Would appreciate your inputs on: Winforms Vs ASP.NET? Communication, Data persistence, Performance, Any other criterion that you might consider important. Your inputs would be highly appreciated. Cheers/RB
RajeevBhatt wrote:
Winforms Vs ASP.NET
Winforms does not really qualify as thin client, and will require setup and deployment. This increases the cost of operations.
RajeevBhatt wrote:
Communication,
It depends on your network architecture. If you have a homogenous corporate network, with well configured internal firewalls, go for the framework that gives you the most functionality, like WCF. If on the other hand, you will have to deal with different authentication mechanisms or domains, or with firewalls that only allow certain types of communication, you may have to kick down to a lower level of in-built functionality.
RajeevBhatt wrote:
Data persistence,
Again, it depends: you may use a persistence framework like the entity framework, but if your data is not well suited to relational operations (and is large enough), you may have to deviate a lot from standard mappings, in order to optimise performance, to the point where a persistence framework becomes more a burden than an asset.
RajeevBhatt wrote:
Performance,
Architecting for performance will again depend on the functionality of the app. Will you be able to scale on different servers, or are the operations single-threaded by nature? Will you be able partition your database, or will the queries by their nature prohibit partitioning. As you see there is no 'right' architecture. Architecture depends on what you want to do. It's the same with building architecture: If you want a lighthouse, you'll probably design a tower-like structure close by the sea. It will probably be unusable as a soccer stadium though :-)