#Server Project Structure

1 messages · Page 1 of 1 (latest)

agile flameBOT
#

<@&987246841693360200> please have a look, thanks.

astral terrace
#

Hello!

I'm just now getting into how to create a HTTP server in Java and I'm sticking to the standard java library. I'd like some input on how you usually structure your server back-end. I am trying to keep it relatively simple so that I can actually finish this project. To give you some context, I am building a server for a fictitious grocery/product store (like Walmart or WholeFoods). I won't be having a ton of entities, just a handful.

I'm mostly interested in how you structure all files related to each entity. Currently, I have only created my classes related to a 'Customer' entity. The image shows my current structure.

Any feedback is much apprechiated! Thanks!

hexed osprey
#

I personally have my dto package separated from entities, rather than having inner packages for each entity. Because everything in the entity package should be an entity and there shouldnt be dto then...

#

Come back to my first message. Just relized you have CustomerService and CustomerRepository inside of the customer package in entity package. This package should only have entities and no services and repositorys. Create own packages for them

sage loom
somber pulsar
#

there are different ways of packaging classes. Packaging by layer (all entities together, all services together, etc) and packaging by component (everything that is related to an entity goes with it). I personally prefer packaging by component as it keeps the source localized to its elements. like you can have entity, dto, mapper, repo, service, etc all in one package. one small benefit is being able to restrict visibility of the repositories to package private and only publically expose the service impl

#

theres not necessarily a right/wrong way of going about it. its just somewhat opinion based. i'd just leave it as u have it and keep going from there. you can always refactor things easily within intellij if u change ur mind

astral terrace
sage loom
#

i have libraries and an example for that

chrome snow
#

they could look through the code to get an idea. but thats structures as a library, and doesnt focus on the structure they're wondering about

sage loom
chrome snow
sage loom
#

and this is where i ended up doing the same thing

#

(at least for the actual HttpServer part).
Implies he's pulling in something for JSON or HTML or whatever

#

he thumbsed up. i shared what i shared. moving on

chrome snow
#

which can be parsed with library tools. would it be more difficult? maybe, but so is creating a server without libraries

chrome snow
#

or was even focused on their problem

#

they could have just been grateful that you wanted to help, or give you props on your library. it doesnt have anything to do with their question though

#

and unless they change their mind about third party libraries, it won't solve their solution. and if they did make that change, there are soooo many other alternatives to this, such as using a proper framework

sage loom
#

he just wanted advice on structure man

#

i'm sure he'll ask if he has follow up questions

chrome snow
#

you saw their structure

#

you saw the question

#

how is your library contributing to it?

sage loom
#

because its not my library, its a project using my library

#

which is structured in a way that can be referenced

chrome snow
#

yes, which is even worse

sage loom
#

its not that deep

chrome snow
#

your library isn't structured anything like what a server would be structured as. its structured as an API meant for use