<?xml version="1.0"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en">
	<id>https://mediawiki.zeropage.org/index.php?action=history&amp;feed=atom&amp;title=ProjectPrometheus%2FMappingObjectToRDB</id>
	<title>ProjectPrometheus/MappingObjectToRDB - Revision history</title>
	<link rel="self" type="application/atom+xml" href="https://mediawiki.zeropage.org/index.php?action=history&amp;feed=atom&amp;title=ProjectPrometheus%2FMappingObjectToRDB"/>
	<link rel="alternate" type="text/html" href="https://mediawiki.zeropage.org/index.php?title=ProjectPrometheus/MappingObjectToRDB&amp;action=history"/>
	<updated>2026-05-14T13:01:31Z</updated>
	<subtitle>Revision history for this page on the wiki</subtitle>
	<generator>MediaWiki 1.39.8</generator>
	<entry>
		<id>https://mediawiki.zeropage.org/index.php?title=ProjectPrometheus/MappingObjectToRDB&amp;diff=37762&amp;oldid=prev</id>
		<title>imported&gt;Unknown at 05:24, 7 February 2021</title>
		<link rel="alternate" type="text/html" href="https://mediawiki.zeropage.org/index.php?title=ProjectPrometheus/MappingObjectToRDB&amp;diff=37762&amp;oldid=prev"/>
		<updated>2021-02-07T05:24:05Z</updated>

		<summary type="html">&lt;p&gt;&lt;/p&gt;
&lt;p&gt;&lt;b&gt;New page&lt;/b&gt;&lt;/p&gt;&lt;div&gt;고려해야 할 것 : 현재 만들어진 Logic Object 들 : Database 의 연동.&lt;br /&gt;
&lt;br /&gt;
참조 문서 : http://martinfowler.com/isa/OR-mapping.html&lt;br /&gt;
&lt;br /&gt;
대강 예측 데이터 &lt;br /&gt;
&lt;br /&gt;
     사용자 데이터&lt;br /&gt;
         For Login&lt;br /&gt;
 &lt;br /&gt;
         For Recommendation System (Read Book, point )&lt;br /&gt;
     책 데이터&lt;br /&gt;
         For Book Information&lt;br /&gt;
         For cauBook Information (중대 도서관시 유일한 키)&lt;br /&gt;
             서지번호(key), 도서관코드(ATSL)&lt;br /&gt;
         For Recommendation System ( Related Book Point )&lt;br /&gt;
&lt;br /&gt;
ProjectPrometheus 는 RDB-Object 연동을 할때 일종의 DataMapper 를 구현, 적용했었다. 지금 생각해보면 오히려 일을 복잡하게 한게 아닌가 하는 생각을 하게 된다. Object Persistence 에 대해서 더 간단한 방법을 추구하려고 노력했다면 어떻게 접근했을까. --[[1002]]&lt;br /&gt;
&lt;br /&gt;
----&lt;br /&gt;
Xper 에 O/R 맵핑 조언 구했을때 그에 대한 답변&lt;br /&gt;
* 고민할 필요 없다; 상당히 귀찮아 보이지만, 실제 전체 작업에서 차지 하는 양은 얼마 되지 않는다. 괜히 라이브러리 만들려고 하면 더 복잡해질것이다. O/R 맵핑 라이브러리로 포커스를 맞추게 되지 않도록 조심.&lt;br /&gt;
&lt;br /&gt;
PEAA 의 RDB Mapping 과 관련된 패턴을 바로 적용하는 것에 대한 답변&lt;br /&gt;
* 패턴의 오/남용 문제가 발생할 수 있다. - 어설프게 아는것은 모르느니만 못한 경우가 있다. 그리고 제대로 안다고 해서 &amp;quot;많이&amp;quot; 하는 것은 정말 잘 아는게 아닐 수 있다. &lt;br /&gt;
&lt;br /&gt;
한편으로 [http://www.xpuniverse.com/2001/pdfs/EP203.pdf Up-Front Design Versus Evolutionary Design In Denali&amp;#039;s Persistence Layer] 의 글을 보면. DB 관련 퍼시스턴트 부분에 대해서도 조금씩 조금씩 발전시킬 수 있을 것 같다. 발전하는 모양새의 중간단계가 PEAA 에서의 Table/Row Gateway 와도 같아 보인다. &lt;br /&gt;
&lt;br /&gt;
 단, 이 논문을 보면 약간은 의문이 드는게&lt;br /&gt;
# 13개월 프로젝트인데 2만라인짜리라는점 - 뭐.. 꼭 소스 라인수로 세는건 무리가 있긴 하지만. Servlet 프로젝트 2만라인. 내가 전에 팀 프로젝트로 MFC 엑셀 만들때가 1만 7천라인이였는데. -_-a 물론, Refactoring 이 잘 되어있고, XP 가 잘 적용된 프로젝트이라면 적은라인수로 많은 일을 하겠지만.&lt;br /&gt;
# 초기에 UpFrontDesign  로 나간 뒤, 후기에 점진적 발전을 추구한점 - 두개가 비교대상이 되긴 어렵다. &lt;br /&gt;
&lt;br /&gt;
----&lt;br /&gt;
[[ProjectPrometheus]]&lt;br /&gt;
&lt;/div&gt;</summary>
		<author><name>imported&gt;Unknown</name></author>
	</entry>
</feed>