How does my business logic interact with my data layer?

Question

So, I am working on a draft of my program.

This is my plan:

GUI --- Business Logic --- Data 

You can replace the GUI or Data layer without any problems. Each layer observes itself. Therefore, the GUI will call methods from Business logic , and the methods will always return the status and, possibly, some data. How the GUI should respond to data should always be defined in the GUI layer. Business logic should not affect this. Thus, relations with the GUI and business logic were resolved. I hope you can follow me.

Now for something more specific. My data layer plan is to use a database. Now, how are Business Logic methods called from the data layer?

Perhaps I need to make an enumeration corresponding to various hard-coded SQL queries that are known at the data level?

eg.

 Datalayer.GetResults(Queries.GetAllCustomersIDs); 

Requests representing an enumeration.

If this is the right way, what should GetResults do? array of strings? but what if the request has multidimensional data?

Should I use 2 common methods instead?

 Datalayer.GetSingleDimensionResults(SingleDimensionQueries.GetAllCustomersIDs); Datalayer.GetMultipleDimensionResults(MultiDimensionQueries.GetAllCustomers); 

Or maybe I have a query for each type of data request?

 Datalayer.GetAllCustomerIDs; DataLayer.GetAllCustomers; 

and etc.

Answer 1

In general, I use:

Data level:

To access the data, I create an interface for each object. Each interface lists all methods for accessing publicly available data for a given object. To store data, I create container types for each object, which can be structures or simple classes with only data. I also rely on a language dataset, such as lists, to store my data, so I am not tied to a specific type of database. After that, I create a class that implements data interfaces, this class has all the SQL and access to the database, so if the storage technology changes, this is the only class that will be changed.

Business level:

It should be called and in what order all the logic with the data should be called, how to check which methods from the data interfaces. This class receives and “sends” data to a data warehouse or graphical interface using containers (for example, lists), where the data types are my containers mentioned above.

GUI:

Invokes business logic methods and presentation / presentation data format. There is no logic here but to invoke the correct business logic methods.

An example of a small container code (C #)

  //Interface for Department class data access. DataStorage assembly namespace DataStorage { public interface IDepartmentDS { void Open(); //Open data conection void Close(); //Close data conection List<Repositories.Department> List(); //Gets all departments (from data base) } } //This class holds all data regarded a department. There no logic here. Repositories assembly namespace Repositories { public class Department { [Browsable(false)] public Department() { } [Browsable(false)] public Department(String Symbol, String Name) { this.Symbol = Symbol; this.DeptName = Name; } public Department(Department department) { this.Symbol = department.Symbol; this.DeptName = department.DeptName; } [Browsable(false)] public String Symbol { get; set; } public String DeptName { get; set; } } } //This class implements the data manipulation itself, accessing the real database. //However the data exchange outside this class is done via repositories classes and //Generics - Lists mainly public class DataStorage : IDepartmentDS { //Here I use to put generic functions to connect with the database, format stored //procedure parameters list etc. //Implementation of the List method declare in the Department Interface List<Repositories.Department> IDepartmentDS.List() { String query = String.Format("SELECT * FROM {0}", DepartmentTable); int rows = 0; DataSet ds = ExecSqlCommand(query, out rows); //this method is private to this class if (ds == null) return null; List<Repositories.Department> list = new List<Repositories.Department>(); foreach (DataRow row in ds.Tables[0].Rows) { list.Add(new Repositories.Department((String)row[DepFN_Symbol], (String)row[DepFN_DepName])); //DepFN_Symbol and the others are just const variables representing the column index } return list; } } public class DepartmentLogic { public DepartmentLogic() { ..... } public List<Repositories.Department> GetAllDepartments() { //Here I create an Instance of the DataStorage but using the Department interface //so I restrict the access to Department data methods only. It could be a good //idea here to use the factory pattern. IDepartmentDS department = (IDepartmentDS) new DataStorage(); department.Open(); List<Repositories.Department> departments = department.List(); department.Close(); return departments; } } 

This example of business logic is really very simple, it just shows how to retrieve data from the storage tier, but as long as you have access to the data, you can manipulate it the way you want. Just a comment here: perhaps this solution should be changed if it is implemented on a very busy server with thousands of applications, since it can use a lot of memory.

For business logic and the UI point of view, all data is transferred between modules using general-purpose containers such as lists. The connection point between all these modules is the container classes, so all classes are more or less decoupled.

The user interface makes orders business logic classes, so it acts as a service provider. Thus, changing the user interface will not affect the classes below.

Business logic requests and sends data to data storage classes using general-purpose data, so changing a database / storage technology should not affect it.

The way I use and I'm trying to improve it;)

Answer 2

Your Layer data should probably be more than a set of semantic queries, and you must encapsulate it in an API, otherwise your business logic level will need to know too much about the implementation of your data level. The same reasoning that you used between the GUI and Business Logic layers should apply for the same purpose.