I have a video-club management application implemented in Java, in which i followed the relatively general MVC architectural pattern.

1. my model consists of java classes mapped to database tables via Hibernate
2. my view consists of various frames in which the only logic directly implemented has to do with button listeners; database operations are called from the Controller.
3. my controller consists of a class in which various database operations for my objects as well as other functions are defined ( save(Customer cust), delete(Customer cust), List <Customer> getCustomers() and so on ).

I was told that it is not necessary to follow only one design pattern and that since MVC deals with the overall structure of the application in a more wide/general way, i can find other design patterns that deal with more specific parts of the application.
I have been looking for quite some time.
My confusion starts with the use of Hibernate; i found some patterns that deal with similar situations such as Active Record or DAO but i cannot tell for sure that my design follows the same rules.

I cannot understand why active record pattern is related and compared with hibernate (http://www.javalobby.org/articles/activeobjects/). Supposedly you can use more than one design patterns, how is it possible to have MVC and active record, when in AR you have to define database operations in the model (http://www.martinfowler.com/eaaCatalog/activeRecord.html) while with MVC and hibernate the model has nothing to do with the database directly.

I know that design patterns are meant to be used as solutions to problems and should be selected and followed before you actually start implementing the application, but any suggestion regarding which design pattern might fit in order to search for more information would be really appreciated.

Since i am not a developer and this application is my BSc's Final year project, in order to avoid any misunderstanding, the suggestions i am looking for, are meant to be a simple guide in terms of "check for this" or "no you got it wrong" rather than the actual solution.

stathisoeo wrote:
I was told that it is not necessary to follow only one design pattern

Very correct.

and that since MVC deals with the overall structure of the application in a more wide/general way, i can find other design patterns that deal with more specific parts of the application.

Not a given.

I know that design patterns are meant to be used as solutions to problems and should be selected and followed before you actually start implementing the application

Mostly true.

Since i am not a developer and this application is my BSc's Final year project, in order to avoid any misunderstanding, the suggestions i am looking for, are meant to be a simple guide in terms of "check for this" or "no you got it wrong" rather than the actual solution.

Hibernate is not a pattern. Hibernate uses patterns.

If the real point is that you need to demonstrate the use of patterns then Hibernate is unlikely to be a good choice. If that is the goal then you would create your own DAOs and perhaps DTOs. You could add a factory in there as well. Probably even an abstract factory since it isn't a real product.

So, is the tail wagging the dog or the other way around? By that, I mean you will either end up creating your tables to resemble your objects or vice versa. Relational and object oriented are different concepts. Many times, you can map one-to-one, but there are enough differences to make it a headache.

2. my view consists of various frames in which the only logic directly implemented has to do with button listeners; database operations are called from the Controller.

Seems ok. Swing, I presume?

3. my controller consists of a class in which various database operations for my objects as well as other functions are defined ( save(Customer cust), delete(Customer cust), List <Customer> getCustomers() and so on ).

These operations are typically done in a data access object. Your controller will typically only need a single piece of information, such as the primary key of the record, to pass to the DAO. (Of course for something like an update or create operation, you need to also supply these values or pass in a fully assembled Customer object, like you are doing above, but for a simple select or delete, you don't need the whole object per se).

>

I was told that it is not necessary to follow only one design pattern and that since MVC deals with the overall structure of the application in a more wide/general way, i can find other design patterns that deal with more specific parts of the application.

The terms are a bit fuzzy here, generally. I personally view MVC as an architecture rather than a design pattern. It suffuses the entire application. You will use many other actual design patterns alongside MVC. Typically, a pattern is employed for a specific task.

I have been looking for quite some time.
My confusion starts with the use of Hibernate; i found some patterns that deal with similar situations such as Active Record or DAO but i cannot tell for sure that my design follows the same rules.

Don't simply use a pattern for its own sake. A DAO is straightforward enough that I would be surprised not to find it in a non-trivial application. Simply place all persistence logic for a given domain object in a separate object. Hibernate (or any ORM tool generally) allows your regular domain object to become an active record.

MVC is your architecture. Hibernate allows a POJO (plain ole java object) to be an active record. Typically, you still want a DAO. But if all your object does is crud (create read update delete), then you can either have one generic DAO to handle such objects, write a DAO for each, or dispense with the DAO entirely. You can still have any number of other patterns being used (visitor, strategy and memento are very common in code).

I know that design patterns are meant to be used as solutions to problems and should be selected and followed before you actually start implementing the application, but any suggestion regarding which design pattern might fit in order to search for more information would be really appreciated.

See above. Don't start by saying, "I want to use this pattern, where will it fit?" Rather, start by sketching out your solution at a high level, without consulting any patterns. Then look at what you have and see if any patterns show themselves. Pattern-fever is a disease that afflicts many when they first start using design patterns.

Since i am not a developer and this application is my BSc's Final year project, in order to avoid any misunderstanding, the suggestions i am looking for, are meant to be a simple guide in terms of "check for this" or "no you got it wrong" rather than the actual solution.