none
Re-usable Login Interface (help) RRS feed

  • Question

  • Hey guys.  I'm pretty new to object-oriented design.  I've been working in VB.NET for about 2 months now.  I'm trying to layout the design for a project I'm working on and I'd like to get some opinions on the overall structure.

    Here's the concept:

    I need to design a common WPF login form component that can be used as the login interface for multiple client-server applications.

    Some of the applications that call this component will interact with a MSSQL server/database, some will interact with MySQL server/database, and some will have the ability to interact with both.

    The login form for a MSSQL server application will contain the following elements:

    Server name (combo box)
    Database name (combo box)
    Use Windows Authentication (checkbox)
    User name (text box)
    Password (check box)

    The login form for a MySQL application will be similar except it will not include the "Use Windows Authentication" checkbox.  The login form for an application that can login to either server type will have an extra radio button to indicate which one to use.  Selecting the "MSSQL" radio button option would enable the "Use Windows Authentication" checkbox.

    Some of the functions required of each of the concrete "ServerLogin" objects will be "GetAvailableDatabases", "BrowseNetworkServers", "GetLoginHistory", etc.

    I need to bind the UI elements to a backing object.  Should I create an abstract base "ServerLogin" class and then have two sub-classes "MSSQLLogin" and "MySQLLogin" and let form load event decide which type of object to instantiate based on the application's stated requirement? 

    Here are some questions I've been pondering:
    1. Is inheritance appropriate here or is there a better approach?
    2. Should the UI-bound object be considered a "Server" or is "ServerLogin" more appropriate?
    3. Should I be looking into using the Factory Method design pattern?
    4. Each server will have a collection of available databases.  Each database will have a simple set of properties that may differ slightly between MSSQL and MySQL - should I use inheritance here, too?

    I'm doing fine hashing out the specific implementation of the methods I need for each of my operations, but I'm very confused about how to architect the framework. 

    Any advice will be greatly appreciated!

    Thanks!

    -rsobers
    Monday, September 15, 2008 12:12 AM

All replies

  • Looks like you are doing a good job for starting OO...

     

    I am gonna try answering some of your questions.

     

     rsobers wrote:

    1. Is inheritance appropriate here or is there a better approach?

    Yes.

     

     

     rsobers wrote:

    2. Should the UI-bound object be considered a "Server" or is "ServerLogin" more appropriate?

    I think you are asking about how to name the object.  This could be philosophical, I would create it as DBServer.

     

     rsobers wrote:

    3. Should I be looking into using the Factory Method design pattern?

    Yes, factory pattern could fit good for this problem.

     

     rsobers wrote:

    4. Each server will have a collection of available databases.  Each database will have a simple set of properties that may differ slightly between MSSQL and MySQL - should I use inheritance here, too?

    Yes, you may use inhertiance.  I would actually look into Dependency Injection like Unity or Ninject or SpringFramework.NET.

     

    { Gaja; }

    http://gajakannan.com/netarch.aspx
    Monday, September 15, 2008 2:15 AM
  • Thanks for the reply.

    My "Database" object is going to be very light weight.

    MSSQL fields:

    Name
    AppRole
    AppRolePassword

    MySQL fields:

    Name

    Should I create a general "Database" object with all 3 fields and just leave AppRole and AppRolePassword empty when I instantiate a MySQL database?  Or does this warrant a base "Database" class with just a name field and a subclass for "MSSQLDatabase"?

    I'm trying to understand if subclassing is warranted even when there are very slight differences.


    Monday, September 15, 2008 1:41 PM