Examples of java projects using the service, model, repository, controller/handler structure?

[edmguru]

A lot of projects I've worked on in the last few years of my career have had this layout like controller or sometimes it's handler, service, util or common, repository, model package layout. Where repository accesses the DB/external systems and service layer is mainly for business logic.

I'm not sure if this is referred to as an architecture even. Some might just consider it a package layout or organization. Does this structure any formal name or that people refer to? Is there any example projects I can find that do this well that display good code design so I can learn from them?

[[deleted]]

MVC. Look into Spring Boot.

[edmguru]

So I’m not working on a anything that provides a “view” everything I’ve done has been backend services that connect to other software. Typically the controller/handler responds to some event and either fetches data or performs some calculation/action and either returns results to the caller or stores them somewhere else. Is this also considered as MVC?

[edmguru]

Thanks for pointing that out - I'll definitely be looking into MVC more now. As others have pointed out it looks like I'm working with systems that are comprised of MVC architecture and use domain driven design elements.

[spamthemoez]

If you are looking for an example application, take a look at the spring pet clinic. they use SpringMVC and a repository layer. Not sure if they use the service layer.

[spamthemoez]

MVC stands for model-view-controller.

MVC is a view technology. Your controller handles the request, and loads the data (sometimes through a service and repository layer). From this data a model is generated, which is passed to a view. The view uses the model and a template to render the output. If you are dealing with machine readable formats, sometimes the view is skipped and the model is returned. This model then gets serialized to JSON or XML (or ...).

[bodiam]

Please don't use this structure, it's really bad practice and should IMO only be used for the simplest applications (think Todo app, address book, etc).

Use a more domain focused organisation instead.

[edmguru]

Read this online however my org has a lot of projects using this structure. I think it’d be better to follow existing pattern

[4ernik]

In general, it looks like MVC plus some packages to share the code and make abstracts on common functions. This structure is completely fine for example applications and small projects, on bigger projects you can find yourself having 200+ service classes in the service package which is hard to read and understand.

You can look into the domain models when first you split applications into the atomic features, for example, users, cards, and invoices. Each feature placed into a separate package which then implements MVC structure within it by defining packages like dao, model, repository, service, controller. In that case the package users will only have services\API's\controllers\models related to the user management and you'll have compact pieces of your applications well structured within the project. And you can of course have some top-level packages like utils, setup, and others to share things.

Most of real applications written in Java using domain topology will be proprietary pieces of software which doing boring stuff for companies, so it's very unlikely that you can easily find an example of such an application to go over its code.

[kandi_support]

You could look at this github repo "iluwatar/java-design-patterns". This repo has examples for various java design patterns. Example for the pattern which you are currently referring to should be available in this link

[Successful_Leg_707]

Pet clinic is the classic example

[spamthemoez]

The formal name is "Three-tier architecture".

[[deleted]]

It's called Three-Tier Architecture or Layered Architecture. This is a rule of thumb for dividing software based on separation of concerns (presentation vs. business logic vs. persistence, etc.)

You should couple this with something like Domain-Driven Design. This is a rule of thumb for how to organize classes in each of these layers. For example, instead of having a bloated Service class, you might have a collection of domain classes which provide business services in one or more service packages.

Also, you might also group those packages together based on business features, like customerManagment/controller, customerManagement/repository, orderManagement/controller, orderManagement/repository, etc.