/database/

>>57012010
do you go to ship?

>>57012175
Come again?

>>57012213
nevermind. I'm a student at ship, and we are doing pretty much the same thing in my architectures class.

ORM ist you friend

>>57012225
How do you solve this shit?

>>57012244
I'm afraid to use it because I keep reading stuff like this:
http://stackoverflow.com/questions/452385/what-java-orm-do-you-prefer-and-why

Create a static DatabaseHandler class and a DatabaseHandlerFactory to get references to it :)
You chose to be ENTERPRISING anon

>>57012261

well first off, you should have a gateway class, that acts as a well, gateway, to the database. It handles connecting, closing, rolling back transactions, starting transactions, etc... then all connections and such will happen through the gateway.

pretty much you have a domain layer, then a mapping layer (takes care of mapping the domain to the data source and vice versa), and that's it. there are several ways in which you could implement the mapping. if you really want to make things super clean, then the domain should have zero knowledge of the data source.

domain <- mapping / persistence -> data source

also, you could factor out a lot of duplication in your mapping / persistence layer.

it can get pretty complicated. here's a good paper -

http://www.agiledata.org/essays/mappingObjects.html

>>57012244
ORM is a meme. Tables of a properly normalized database almost never map to domain objects 1:1.

Yes, writing data mappers is a pain in the ass, but if you don't want to end up with terribly designed DB and/or business logic, as well as inefficient as fuck queries, it's the only way to go.

>>57012325
Thanks, I will definitely read that paper.

At the moment I was thinking about doing this:

Give every Class a public static Orm object. Obj is an interface that has stuff like "add to database" and "update" and shit

So something like Apple has a public static AppleOrm object that implements the Orm interface and also has extra ORM functionality specific to apples.

Sounds alright to you?

( I know it's not 100% clean because there's a tiny bit of Model/Mapping overlay, but I don't mind making that little sacrifice if it will speed up my workflow)

>>57012465
open closed principle nigga

Just write the class to handle ALL things SQL first and see if you can work with it. If not, keep improving it until you can. THEN you can integrate it into your project.

>>57012281
This is what I tried at first, but I found out day 1 that DatabaseHandler would be 5 million lines long. So now I'm thinking about doing >>57012465

>>57012485
>Just write the class to handle ALL things SQL first and see if you can work with it.

Already did this. The answer is "no".

>>57012508
Then you can't SQL and have some learning to do. You came here for advice, you got it.

>>57012010
>connection to the database, create a prepared statement, interpret the resultset, close the resultset, close the prepared statement, close the connection
Pretty much, yes. The close statements will cascade though, closing a statement will close any resultsets it created etc. Read the documentation for more information.

Also you don't want to create a new connection for every query, the SQL server will crap on you very quickly if you do that with any decent userbase. What you should have is a ConnectionManager class that holds a connection pool and hands connections one by one. In small projects you can just have one actual connection that stays open untill you close the program.

>>57012530
No, I mean I can do it, but it's extremely inefficient so I started looking for another solution pretty soon.

Back when I did manual database stuff with Java it looked something like this:

public List<User> getUsers() throws CustomAbstractionException {
    try (PreparedStatement stm = conManager.getConnection()
                        .prepareStatement(statement_as_static_final_variable)) {
        stm.setString(1, "whatever");
        ResultSet res = stm.executeQuery();
        List<User> list = new ArrayList<>();
        while (res.next()) {
            list.add(new User(
                res.getString("name");
                res.getString("foo");
            ));
        }
        return list;
    }
    catch (SQLException sqle) {
        throw new CustomAbstractionException(sqle, "some sort of default description");
    }
}

So basically use holder objects to transfer data back and forth from application layer to database layer. And abstract everything, do the whole thing as a class that implements your own database interface and keep the SQL exceptions away.

I havent touched actual SQL code in ages though, Spring JPA is good enough for me. Might be that you're supposed to use it differently.