Справка по дизайну классов - PullRequest
1 голос
/ 21 апреля 2009

У меня есть следующие таблицы базы данных, с которыми я работаю, и я вроде как новичок в работе, так что я решил спросить здесь.

assignment
----------
id
person_id
assigned_address_id
position_id

person
----------
person_id
current_address_id
name
ssn
drivers_license

address
---------
id
address_number
address_street
address_city
address_state 
address_zip

position
---------
id
description
rate

Я создал следующие классы

Person Class
int? id
Address currentAddress
string Name
string ssn
string drivers_license

PersonAssignment Class
id
person_id
Address assignedAddress
Position assignedPosition 

Address Class
string address_number
string address_street
string address_city
string address_state 
int address_zip 

Position Class
int? id
string description
double payment_rate 

Я также создал классы обслуживания Seprate для каждого из объектов, которые обращаются к Dal.Repository и выполняют методы crud для каждого из объектов. т.е.

PersonService Class
Update(Person p)
Insert(Person p)
GetListOfPeople()
GetPerson()

PersonAssignmentService Class
Update(PersonAssignment p)
Insert(PersonAssignment p)
GetListOfPeopleAssignments()
GetAssignment()

У меня также есть хранилища для каждого из объектов

1012 * т.е. *

PersonRepository Class
Update(PersonAssignment p)
Insert(PersonAssignment p)
GetListOfPeopleAssignments()
GetAssignment()

На моей веб-странице, которая содержит сведения о назначении лиц и персональные данные этих лиц, я звоню PersonService и PersonAssignmentService.

Это похоже на большую работу. Я делаю что-то неправильно? Может быть, есть более простой способ создать что-то подобное, и я просто не понимаю.

Спасибо за любую помощь

Спасибо

Ответы [ 5 ]

1 голос
/ 21 апреля 2009

Что вам нужно сделать, это спроектировать и реализовать слой доступа к данным:

http://rlacovara.blogspot.com/2009/02/high-performance-data-access-layer.html

Эта статья является лучшей из тех, что я когда-либо видел, описывая, как вы будете писать слой доступа к данным. Автор описывает, что вам нужно создать DTO (объекты транспортировки данных) для перемещения ваших данных из уровня доступа к данным на бизнес-уровень (или в другой уровень, где они могут быть преобразованы в собственные классы приложений). Он предоставляет базовые классы и код, чтобы помочь вам с объектами транспортировки данных, кодом для заполнения DTO и кодом для сохранения DTO в базе данных.

В серии три статьи, и я рекомендую прочитать весь набор.

0 голосов
/ 21 апреля 2009

Похоже, вы работаете в среде, которая была разработана кем-то другим, где у вас есть классы служб, репозитории и DAL, и теперь, когда у вас есть все эти вещи, вы смотрите на большую кучу кода и спрашивая "не существует ли более легкий путь". Короткий ответ - да, всегда есть более простой способ. Существует столько же способов доступа к данным, сколько существует разработчиков. Модель, которую вы используете, довольно сложна и звучит так, как будто она соответствует принципам доменного дизайна. DDD - отличная методология, которая обеспечивает отличное разделение проблем и высокую тестируемость. Но это также требует большого количества программного кода и не очень хорошо понимается большинством программистов .Net, поэтому получить помощь может быть сложно. Я думаю, что это лучший способ создания корпоративных приложений, но это не лучшая модель для вас, если вы новичок в ООП.

Если вы делаете небольшой проект, вам может потребоваться вообще обойти BLL: нет классов служб, нет репозиториев, просто есть проект Common Lib /, содержащий ваши классы сущностей, и создайте DLL, содержащую методы доступа к данным, которые непосредственно заполняйте и сохраняйте свои объекты.

Еще более простой подход состоит в том, чтобы покончить с классами сущностей и просто заставить вашу DLL возвращать ADO.Net DataTables, которые содержат данные вашей сущности. При таком подходе теряется строгая типизация класса сущностей, но его гораздо проще реализовать.

Другой подход заключается в использовании Entity Framework. EF сделает все это за вас и сгенерирует строго типизированные классы сущностей. Это займет немного времени, чтобы привыкнуть к EF, но как только вы поймете, как с ним работать, это может значительно сократить время, необходимое для написания персистентного кода. Для некоторых хороших обучающих программ по EF, проверьте блог Роба Бэгби

0 голосов
/ 21 апреля 2009

В зависимости от ваших правил, похоже, что у каждого человека может быть только один адрес, поэтому, если кто-то перемещается, вы теряете его последний адрес, так как в таблице адресов нет person_id.

Но это придирки.

Использование DAO, как упомянуто выше, является отличной идеей. Держите логику отдельно.

Я бы начал с написания DAO, удостоверился, что он делает все, что должен, а затем работал на следующем уровне, чтобы вы могли вносить любые необходимые изменения в базу данных.

Если вы новичок в C #, возможно, вы захотите взглянуть на различные инструменты, которые предоставляет .NET 3.5, так как было сделано много изменений для упрощения доступа к базе данных, чтобы абстрагироваться от реальной базы данных.

Одним из преимуществ этого является то, что некоторые из ваших источников данных могут быть получены из файла XML, и ваш DAO будет работать нормально независимо от фактического источника источника данных.

0 голосов
/ 21 апреля 2009

Я не уверен на 100%, что делает ваша веб-страница, но при условии, что у вас есть идентификатор PersonAssignment и вы извлекаете из него объект PersonAssignment, а затем сам объект Person, следующее может упростить:

В классе PersonAssignment добавьте свойство, ссылающееся на объект Person, а не просто person_id. Из вашего примера:

PersonAssignment Class
id
person_id
Person person
Address assignedAddress
Position assignedPosition

В методе GetPersonAssignment (который, как я предполагаю, принимает параметр), выполните некоторую работу для заполнения объекта Person. Вам необходимо добавить методы вставки и обновления, чтобы учесть это.

0 голосов
/ 21 апреля 2009

Дизайн базы данных и классы иногда могут быть трудны для критики, и многое из этого действительно зависит от ваших бизнес-правил и типа транзакций, которые у вас есть.

Для начала у меня не было бы отдельной таблицы для адреса человека, и я бы не создавал какой-либо определенный класс, который определяет и Address.

Я не уверен, какой язык программирования вы используете, но, вероятно, стоило бы потратить время на ознакомление с ORM (объектно-реляционным отображением)

...