Отображение объекта - выравнивание к свойству вместо ссылки на объект

Question

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

Внутри BLL, и в случае, если я использую настраиваемые бизнес-объекты в BLL, такие как CustomerInfo {FN, LS, ...}, учтите, что у меня есть таблица Customer и таблица Currency, у Customer есть валюта по умолчанию, поэтому это FK Currency_ID в таблице Customer, на уровне пользовательского интерфейса нам нужно показать символ Currency вместо Currency_ID. (ВЫБЕРИТЕ ... ВНУТРЕННЕЕ СОЕДИНЕНИЕ ..)

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

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

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

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

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

Спасибо

Answer 1

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

Джо Селко http://www.celko.com/ особенно поддерживает этот подход.

Celko на SQL: объяснение естественных, искусственных и суррогатных ключей http://intelligent -enterprise.informationweek.com / showArticle.jhtml;? JSESSIONID = EJ2IXIZ2R4MSLQE1GHOSKH4ATMY32JVN идентификатор_статьи = 201806814

Answer 2

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