CODEWITHSUNDEEP
c#.netwinformsn-tier-architecture
user850010
user850010

Reputation: 6359

Few questions regarding BLL and DAL in my first 3-tier Winform Application

I am trying to create 3-tier winform application. Since this is my first attempt of 3-tier design, I got stuck and have few questions.

The application will support attaching multiple sqlite db files.

So I created class like this

public class Database
{
    public string Name { get; set; }
    public string FilePath { get; set; }
    public bool isAttached { get; private set; }
}

Now I want to have collection of those objects.

Should I create another class like DatabaseList below or is enough to just create a List

public class DatabaseList : List<Database>
{
...

vs

List<Database> myDatabases;

What should be created in Form1.cs?

For example I assume the collection above should be created in BusinessLayer and not in Form1.cs and only BusinessLayer class is created in Form1.cs. Is this correct?

Where to put Attach Method?

The method would be like this: 

    public void AttachDB(Database db)
    {
        MySqliteHelper.Attach(db.Name, db.FilePath);
        this.Add(db);
    }

Do I put the method in DatabaseList class (if this is the way to create collection) or should it be in BusinessLayer?

How to make the Attach method to support additional relational databases like MS SQL Compact Edition which also resides in a single file

I was thinknig of creating another general database helper class with same methods as MySqliteHelper and the AttachDB method would call that instead. Something like

MyDBHelper.Attach(db.Name, db.FilePath);

Or is this where Dependency Injections like Ninject can be helpful? I never used that before and all I am recalling from Ninject is a samurai having different weapons so it seems to me to be kinda similar to my problem having different specific database classes.

Upvotes: 2

Views: 2169

Answers (3)

James Johnson
James Johnson

Reputation: 46047

I'm going to tackle this question in parts because it covers a lot of ground.

What qualifies as a 3-tier architecture?

A 3-tier (or n-tier, tiered) architecture is basically any design where the interface doesn't directly communicate with the database, no matter how thin the actual tiers are. You could create a single class with functions to get and save data, and it would still qualify as a 3-tier architecture. That being said, what I'm going to explain below is probably the most common implementation of a 3-tier architecture.

Layer vs. Tier: What's the difference?

To understand the 3-tier architecture, it's important to first make a distinction between a layer and a tier. An application can have many physical layers and still contain only three logical tiers. If a picture really is worth a million words, the diagram below should clear that up for you.

enter image description here

In the diagram above, the Business/Middle Tier is comprised of business logic, business objects, and data access objects. The purpose of this tier is to serve the middle man between the user interface and the database.

The Data Access Layer (DAL)

The data access layer is comprised of a data access component (see below) and one or more data access objects. Depending on the need, the data acess objects are usually set up one of two ways:

  1. One Data Access Object for each Business Object
  2. One Data Access Object shared by many Business Objects

It sounds like you're going to be dealing with several databases, so it would probably make sense to go with the one-to-one option. Doing it this way you'll have the flexibility to specify which database/connection corresponds to which business object.

enter image description here

Data Access Component

Your data access component should be a very generic class containing only the bare-bones methods needed to connect and interact with a database. In the diagram above, that component is represented by the dbConnection class.

Questions & Answers

What should be created in Form1.cs?

The only thing the front end deals with are the business objects and the business logic. Sometimes it's not that black and white, but that's the idea.

Where to put Attach Method?

Instead of an Attach method, pass a connection string into your data access component. A connection string can be used to attach and/or connect to pretty much any database.

How to make the Attach method to support additional relational databases like MS SQL Compact Edition which also resides in a single file?

See above.

Should I create another class like DatabaseList below or is enough to just create a List?

Honestly, this is up to you and doesn't affect the validity of the 3-tier architecture. You know the specific requirements that you're trying to meet, so do it if it makes sense. Give consideration to how your Data Access Object(s) will interact with this class though, because you will need to expose the methods for executing queries and non-queries on whatever database is selected from the list.

Upvotes: 4

mannu2050
mannu2050

Reputation: 403

You need to think in terms of modularity and abstraction. See you have multiple entities to be passed across layers.

Following are the examples: 1. Presentation will create an object of business layer or business facade. But it will expect the logical entity from business layer.

  1. Business layer will create the object of DataAccess and will expect the logical entity from DataAccess to perform business operations.

  2. DataAccess will do whatever it would like to do to get the information from database. So if you need to connect the oracle / sql /sqllite / files system whatever but it will convert or say initialize the Logical entity (entity is a Class only consisting of properties).

So every layer will have their own responsibility and perform the operation it is responsible for.

So I think your db related operations will go in DataAccess.

Upvotes: 1

Wiktor Zychla
Wiktor Zychla

Reputation: 48230

What you lack is thinking in terms of objects and their responsibility.

What object is responsible for creating instances of your database descriptions? Should it be Form1?

The OOP tells you that if you have such doubts you can follow the Pure Fabrication principle and just create another class to be responsible for this. This is just as simple.

So you can create a class, let call it DatabaseManager, put your list of databases there plus the Attach method. You probably also want this manager to be an ambient class (the same instance shared among other classes) so you can build a Singleton out of it (but this is not necessary).

DI containers could probably help you to organize services and manage their lifetime but I recommend you start with a good book on this before you misuse the idea. Mark Seemann's "Dependency Injection in .NET" is fine.

Upvotes: 2

Related Questions