dto

Im planning to use the Entities generated by the EF (POCO) in sending data to the client instead of creating DTOs? Is this a good practice? Basically, my EDMX file is on my DAL layer. So the UI will have direct access on my DAL. Thanks. dhoelzgen Basically, I don't think it's a good idea to send DAL objects to your interface, so I would use DTOs. To minimize the effort doing so I would take a look at an DTO generator , to generate DTO code which lets you convert from DAL object to DTO and vice versa. EDIT: Sorry, didn't see you are using POCO. Have a look at this SO post It depends on how

版权声明：如需转载，请标注出处 https://blog.csdn.net/weixin_43780471/article/details/91338243 在进行mybatis的操作，如果不想参与接口类的写，就可以用代码补全的DTOHper. 下面就简单的讲解一下如何进行代码接口类的补全 1.首先呢需要创建maven管理的项目，找到相应的jar 2.创建db.properties 里面的参数根据自己的需求定义（一般是数据库的相应连接） dto.driverClass = com.mysql.cj.jdbc.Driver dto.jdbcUrl = jdbc:mysql://localhost:3306/数据库名 dto.user = dto.password = dto.package = 在那个包下 dto.mapper = mapper dto.tablePrefix = 表类型 3.找到引进jar下的主函数 4.将主函数里面的代码复制到自己创建的Test里面 import org.fkjava.dto.support.DTOHelper; public class TestMain { public static void main(System[] args){ DTOHelper dto = new DTOHelper(); try { dto.createDto();

DO： domain object持久对象 就是从现实世界中抽象出来的有形或无形的业务实体。 PO： persistant object持久对象 最形象的理解就是一个PO就是数据库中的一条记录。 好处是可以把一条记录作为一个对象处理，可以方便的转为其它对象。 BO： business object业务对象 主要作用是把业务逻辑封装为一个对象。这个对象可以包括一个或多个其它的对象。 比如一个简历，有教育经历、工作经历、社会关系等等。 我们可以把教育经历对应一个PO，工作经历对应一个PO，社会关系对应一个PO。 建立一个对应简历的BO对象处理简历，每个BO包含这些PO。 这样处理业务逻辑时，我们就可以针对BO去处理。 VO ： value object值对象 ViewObject表现层对象 主要对应界面显示的数据对象。对于一个WEB页面，或者SWT、SWING的一个界面，用一个VO对象对应整个界面的值。 DTO ： Data Transfer Object数据传输对象 主要用于远程调用等需要大量传输对象的地方。 比如我们一张表有100个字段，那么对应的PO就有100个属性。 但是我们界面上只要显示10个字段， 客户端用WEB service来获取数据，没有必要把整个PO对象传递到客户端， 这时我们就可以用只有这10个属性的DTO来传递结果到客户端，这样也不会暴露服务端表结构

在添加店铺Service层编写之前，要先编写添加店铺的返回类型 存储在Dto中 记录添加店铺成功或失败的状态 public class ShopExecution { /** * 状态 为枚举类型，在ShopStateEnum.java中定义 */ //结果状态 private int state; //状态标识(以文字的形式解释state的作用) private String stateInfo; //店铺数量 private int count; //操作的shop（增删改店铺的时候用到） private Shop shop; //shop列表（查询店铺列表的时候使用） private List<Shop> shopList; public ShopExecution() { } //在店铺操作失败时使用的构造器--生成ShopExecution对象 public ShopExecution(ShopStateEnum stateEnum) { this.state = stateEnum.getState(); this.stateInfo = stateEnum.getStateInfo(); } //在店铺操作在成功时使用的构造器-返回一个店铺对象 public ShopExecution(ShopStateEnum stateEnum,Shop shop) { this

What is the general idea to help deciding when to use DTO and when to use Entity in these cases ? UI / server side java calling the services. Should it get / send entities or DTOs ? Web service calling the services. Should the services accept entities or DTOs ? I like reading the code that pass entities around : simpler to pass around, no need to map to DTOs dont need extra classes relations to other entities are already defined, so dont need combine related DTOs into one DTO just POJOs But there are arguments about DTO that maps to an entity is safer, because it's a contract, and the entity

Can someone explain me when I should inherit my controller form ODataController vs ApiController ? The question is caused by the fact that results returned by ApiController can be filtered with OData query. If I apply QueraybleAttribute to contoller's methods, query is processed even if action returns IEnumerable . However without this attribute but with the call config.EnableQuerySupport() , query is processed only if method returns IQueryable . I think it is not consistent behavior. WebAPI documentation and examples imply that controller must inerit from ODataController. And I'm a little

I have a project where we use screen DTO's to encapsulate the data between the Service Layer and the Presentation Layer . In our case, the presentation layer is ASP.Net. The only classes that know about the DTO's are the service layer classes and the Pages/Controls that call these services and display the DTO's. The DTO's are almost always Page/Control specific so I feel they belong in the Presentation Layer, but that would mean the Service Layer would have to reference the Presentation Layer in order to use the DTO's. I'm almost thinking that the Service Layer should return richer objects

After reading some of the Q/As here on stackoverflow, I am still confused about the correct implementation of DTOs in my web application. My current implementation is a (Java EE based) multi-tier architecture (with persistence, service and presentation layer) but with a "common" package used by all layers, containing (amongst others) domain objecs. In this case the layers can not really be considered as independent. I am planning to remove the common package step by step, but I encounter various challenges/questions: Assume the persistence layer would use a class myproject.persistence.domain