Java design question

[jay8anks]

I'm converting a java back-end to a .net core back-end. Finally starting to kind of get a little more comfortable with this, at least.

I have a question on what exactly the purpose of this is.

From: ecommerce-backend/UserCreateDto.java at master · webtutsplus/ecommerce-backend

public class UserCreateDto {

    private String firstName;
    private String lastName;
    private String email;
    private Role role;
    private String password;

    public String getFirstName() {
        return firstName;
    }

    public void setFirstName(String firstName) {
        this.firstName = firstName;
    }

    public String getLastName() {
        return lastName;
    }

    public void setLastName(String lastName) {
        this.lastName = lastName;
    }

    public String getEmail() {
        return email;
    }
    
...etc.
}

I don't quite understand why they would use getFirstName(), setFirstName(String firstName), etc. Reading stackoverflow, it seems like this may be a java thing.

What I see doing is just letting Dapper fill the DTO object and using it.

What they are doing is using the above in their service layer, like this:

 User user = new User(userCreateDto.getFirstName(), userCreateDto.getLastName(), userCreateDto.getEmail(), userCreateDto.getRole(), encryptedPassword );
        User createdUser;

I'm just curious on some observations on this from someone smarter than me.

Thanks,

 

[alexhortdog95]

My Java is a bit rusty, but that is the getter/setter for properties, done the Java way.

It would be equivalent to this in C#:

string FirstName { get; set;}

 

[Skydiver]

And the C++ way. And the SmallTalk way. C#'s automatic properties tries to make the language not as verbose as Java, C++, or SmallTalk.

 

[alexhortdog95]

And the C++ way. And the SmallTalk way. C#'s automatic properties tries to make the language not as verbose as Java, C++, or SmallTalk.

I heard a friend of mine say that C# was Java done correctly

 

[jay8anks]

My Java is a bit rusty, but that is the getter/setter for properties, done the Java way.

It would be equivalent to this in C#:

string FirstName { get; set;}

OK, so I'm correct in thinking I can just use Dapper to populate the DTO object and use it the same way I have been doing with everything else Dapper maps for me?

Since I have been working on this for a few weeks, my thoughts are, I seem to have generated a lot more files and code to do the same thing they are doing in java...but in some areas like this, they seem to have to do a lot more typing to do the same thing.

I'm also a little weak in understanding models vs. DTO objects. I know what DTO objects are for, but they made models and DTO objects that sometimes seem to be the same. And sometimes their DTO objects for creation and updates are pretty much the same. If the the creation DTO and the update DTO are the same, why can't I just make a single DTO object and use it? Does it hurt anything?

And then the thought I have is, if I'm only using this DTO object, why do I have to bother putting it in models, too? Or should I just put it in models and call it a model???

My understanding of DTO objects is, if my FileUploads class has a bunch of variables in it, but if I just need the file name and url, I can make a DTO class and just expose those two things. Am I thinking about that correctly?

/But then I can kind of get around that in places using [JsonIgnore].

 

[alexhortdog95]

OK, so I'm correct in thinking I can just use Dapper to populate the DTO object and use it the same way I have been doing with everything else Dapper maps for me?

Since I have been working on this for a few weeks, my thoughts are, I seem to have generated a lot more files and code to do the same thing they are doing in java...but in some areas like this, they seem to have to do a lot more typing to do the same thing.

I'm also a little weak in understanding models vs. DTO objects. I know what DTO objects are for, but they made models and DTO objects that sometimes seem to be the same. And sometimes their DTO objects for creation and updates are pretty much the same. If the the creation DTO and the update DTO are the same, why can't I just make a single DTO object and use it? Does it hurt anything?

And then the thought I have is, if I'm only using this DTO object, why do I have to bother putting it in models, too? Or should I just put it in models and call it a model???

My understanding of DTO objects is, if my FileUploads class has a bunch of variables in it, but if I just need the file name and url, I can make a DTO class and just expose those two things. Am I thinking about that correctly?

/But then I can kind of get around that in places using [JsonIgnore].

When you say "they," do you mean they as in the Java dev does more typing? If so, that's why C# is a much more attractive language than Java is

Models and DTOs are (someone correct me if I am wrong) are very similar to one another.

From what I can tell, the main difference are that DTOs are objects which allow you to hide references to your database entities you don't want exposed.
Dapper requires models that tie back to your database, and those models are exposed to clients using your API.

If you're looking for a more complex ORM with bells and whistles, then use EF (which has its flaws).
If you're looking for something light weight (also with some flaws, of course), then use Dapper.

Sounds to me you're on the right track in your thinking. Again, this is one man's opinion, FWIW.

 

[Skydiver]

Think of the model as your domain objects. They represent the current state of your system. If you had infinite memory, and you could freeze the state of the system, these are the objects that you will be playing with all that time. Or if you had a read object oriented database and could serialize and deserialize entire object graphs to effectively freeze the state of the system. These objects have behaviors like in that true object oriented programming sense. You send them messages, and they perform some actions.

Data Transfer Objects are ways of communicating between components to try to hydrate and keep the domain objects up-to-date, or to expose parts of the domain object state. DTOs could be a simple as the list of strings that are the names of the actual domain object data, or ints that represent the IDs for those object instances. DTOs could be how you read/write to your database, or transmit to and from your UI. DTOs don't have behaviors. They are just dumb structs.

 

[jay8anks]

When you say "they," do you mean they as in the Java dev does more typing? If so, that's why C# is a much more attractive language than Java is

I meant they, as in the guys that wrote this java back-end for a shopping cart:

GitHub - webtutsplus/ecommerce-backend

Contribute to webtutsplus/ecommerce-backend development by creating an account on GitHub.

github.com

From what I can tell, the main difference are that DTOs are objects which allow you to hide references to your database entities you don't want exposed.
Dapper requires models that tie back to your database, and those models are exposed to clients using your API.

If you're looking for a more complex ORM with bells and whistles, then use EF (which has its flaws).
If you're looking for something light weight (also with some flaws, of course), then use Dapper.

Sounds to me you're on the right track in your thinking. Again, this is one man's opinion, FWIW.

I messed around with EF a long time ago. At the time, it didn't get along very well with MySql. I don't like that it kind of has a black box feel to me. It's kind of like the stock market, in that there is some complexity there that I don't have any control over and that most people don't understand.

In my day job, I mainly do ADO.net. I kind of like writing SQL. lol.

I do like Dapper. In my opinion, it's a good compromise. I still get to write SQL, but it is way less verbose than ADO.net, and plus it does make returning lists easy.

My goal is, I want to get as familiar with webAPIs as I am with Web Forms...to get to the point where I can do them in my sleep like I can Web Forms.

I'm taking a course on React js from UC Santa Barbara right now. And the Vue.js front-end those guys wrote for the shopping cart is actually starting to make sense to me.

MVC just never really clicked with me. I think a React/Vue front-end to a C# webAPI is the direction for me. I'm really interested in some ionic React progressive web apps, as well.

Jay

 

[jay8anks]

MVC just never really clicked with me. I think a React/Vue front-end to a C# webAPI is the direction for me. I'm really interested in some ionic React progressive web apps, as well.

Jay

And if I were to ever really land my dream job, I think I would just work on the server side full time. Part of my problem is, after I write hundreds of lines of code to wire up a form, I really don't care if the buttons look pretty or how it looks on a phone. I really question how so much is expected from full-stack guys.