отображения объекта - уплощение собственности вместо ссылки на объект

Question

Я пытаюсь уточнить свои знания N_Tier арки

Внутри УСК, и в случае я использую пользовательские бизнес-объекты в УСКЕ, как CustomerInfo {FN, LS, ...}. Учтите, что у меня есть таблица Customer и таблица Currency, у Клиента есть валюта по умолчанию, поэтому в таблице Customer есть значение FK Currency_ID, на уровне пользовательского интерфейса нам нужно отображать символ валюты вместо Currency_ID. (SELECT ... INNER JOIN ..)

Могу ли я поместить символ Currency в качестве свойства в CustomerInfo вместо того, чтобы указывать ссылку CurrencyInfo внутри CustomerInfo.

Я думаю, что нет ответа, но почему? Что может пойти плохо?

Должен ли каждый бизнес-стол (исключая проверки) в базе данных отображать бизнес-объект?

Я думаю, что бизнес-объекты (объекты, содержащие данные, полученные в форме DAL) должны быть тщательно сопоставлены с таблицами в базе данных, это может увеличить ремонтопригодность. Но BLL может содержать любые объекты для бизнес-операций и бизнес-проверки.

Пожалуйста, дайте мне несколько книг, или ссылки, чтобы осваивать арку N-уровня и дебаты о ней.

Благодаря

Answer 1

Может быть, вы должны прочитать некоторые из многих прекрасных книг по дизайну моделей (в Wikipedia page on the subject ссылки на некоторые из них). В частности, вы можете найти концепцию объекта передачи данных (DTO) хорошей. Совсем обычной практикой является наличие модели домена, которая тесно связана с вашей базой данных, возможно, используя инструмент объектно-реляционного сопоставления, такой как (N) Hibernate, iBatis и т. Д., Но затем иметь набор преобразователей/адаптеров, которые превращают их в слегка обтекаемые объекты (например, объект CustomerInfo, который вы описываете), которые лучше соответствуют тому, как наше приложение должно отображать и обрабатывать данные.

Answer 2

Если вы хотите использовать символ валюты в качестве натурального ключа в таблице CurrencyInfo, почему бы просто не сделать его первичным ключом в таблице CurrencyInfo?

Joe Celco http://www.celko.com/ особенно защищает этот подход.

Celko на SQL: природные, искусственные и суррогатные ключи Разъяснения http://intelligent-enterprise.informationweek.com/showArticle.jhtml;jsessionid=EJ2IXIZ2R4MSLQE1GHOSKH4ATMY32JVN?articleID=201806814