3

I am wondering about best practices here.

MVC (Model - View - Controller) patterns involve separating components of your program that model the data, manipulate those models, and display those results to the user (usually through the UI) in some way.

What about a function that takes the model data and inserts it into a database? For example I have an object called a GameBoard, and I also want the ability to insert the state of this board into the SQL database for storage / historical purposes. I have a class that holds all my query functions.

But where would I call these functions from? Would this sort of functionality make the most sense to make it as a method of GameBoard? Or should it be part of the controller classes?

For example, I've got a GameBoard class and an SQLDatasource/SQLHelper class (which I call the "models"). The SQL classes have methods that take care of the queries and such. In Android, there are also Activity classes where all the "events" take place (I call these the "controllers"). The "view" takes place via code that binds the Activity to some XML. That being said, I normally instantiate the GameBoards in the Activity classes, and right now I also call the query functions from these same classes that accept a GameBoard as an argument.

Improve this question
3

2 Answers 2

Reset to default
6

A typical (but simplified) MVC architecture looks like this:

Database <-->  Logic Layer <--> Controller <--> View

Your Logic Layer contains the functions that you would call to perform your game-related activities. The purpose of the Logic Layer is to translate your game-related functions into database operations.

Improve this answer
7
  • I always sort of considered the Controller and Logic Layer to be the same. Is this wrong?
    – AJJ
    Commented Mar 28, 2016 at 17:37
  • 2
    The Logic Layer is part of your Model (the M in MVC). Think of the controller as a switch-yard. It accepts your requests, and shunts them to methods that have primary responsibility for performing your game functions.
    – Robert Harvey
    Commented Mar 28, 2016 at 17:38
  • Maybe I should be more explicit. For example, I've got a GameBoard class and an SQLDatasource/SQLHelper class (which I call the "models"). The SQL classes have methods that take care of the queries and such. In Android, there are also Activity classes where all the "events" take place (I call these the "controllers"). The "view" takes place via code that binds the Activity to some XML. That being said, I normally instantiate the GameBoards in the Activity classes, and right now I also call the query functions from these same classes. Is all of this a correct understanding?
    – AJJ
    Commented Mar 28, 2016 at 17:42
  • This is all happening inside your phone?
    – Robert Harvey
    Commented Mar 28, 2016 at 17:42
  • I'm making an Android app, which uses Java, but yes
    – AJJ
    Commented Mar 28, 2016 at 17:43
1

A good approach is the DAO pattern.

Use a DAO class per entity to handle any SQL related functionality.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.