dto dao poco bo
-
05-07-2019 - |
문제
사실 나는이 용어와 그들이 서로의 관계에 대해 꽤 혼란스러워합니다. a 그들 모두에 대해 뭔가를 읽었지만 나는 작업 흐름을 쫓아 내지 않습니다 ..
DTO- 데이터 전송 객체 - 전송 값에 대한 개체
BO 비즈니스 객체 - 도메인 모델의 객체. 비즈니스 로직을 만드는 개체
Poco- 모르겠지만, 나는 위키에 대한 정의를 읽었지만 아무것도 이해하지 못했습니다.
DAO- 데이터 액세스 객체 - DB 테이블을 맵핑 할 객체?
누군가 나를 위해 약간의 빛을 가져다 줄 수 있습니까?
해결책
- DTO: Data Transfer Object, used to transfer data between loosly coupled services
- POCO: Plain Old Clr Object, normal CLR object doesn't use any attributes or required inheritance to act as a DAO/DTO
- BO: Business Object, contains business logic, used in the Business Logic part of your solution
- DAO: Data Access Object, used to transfer data from your database
So a regular workflow would be to request data from a service, which is sent to your app as a DTO, you convert it to a BO to manipulate it and send it back as a DTO or after converting it to a DAO store it in a database.
You use the different object to separate concerns between the 3 types, a BO doesn't need to know whether it's persisted using a database or a service.
다른 팁
Timeline based scaffolding:
Batch => Stored Procedure => "plain old clr object" => npmagenda
Socket => ODBC => "data access object" => NoSQL
CSV => XML => "data transfer object" => JSON
FTP => CGI => "business object" => AJAX
References
- How to schedule and automate backups of SQL Server databases in SQL Server Express
- npmjs: agenda - Light weight job scheduler for Node.js
- Corba, XML and ODBC
- webdav by hand
- Export MVC WebGrid to Excel (CSV)
- Stored Procedure POCO Generator Utility for SQL Server
- Technical Standard Systems Management: Data Storage Management (XDSM) API (pdf)
- JVM to .Net Interop