Ответ 1
Я думаю, что у вас просто проблемы с определением того, что каждый слой и какую роль он играет в вашем решении.
Уровень данных
Ваш уровень данных - это просто ваша база данных/список SharePoint/.csv/excel sheet... вы получаете идею, она просто там, где хранятся ваши данные, и может быть в любом формате. Поэтому помните, что уровень данных - это не что иное, как просто данные.
// ----------------------------
// Data tier
// - MySQL
// - MS SQL
// - SharePoint list
// - Excel
// - CSV
// - NoSQL
// ----------------------------
Уровень доступа к данным
Этот слой абстрагирует ваш источник данных и предоставляет API, в котором остальная часть вашего приложения может взаимодействовать с источником данных.
Учтите, что наш источник данных - это база данных MS SQL, и мы используем Entity Framework для доступа к данным. То, что вы будете пытаться абстрагироваться, - это база данных и Entity Framework, а для Entity
- Data Repository
.
Пример...
У нас есть таблица Customers
в базе данных MS SQL. Каждый клиент в таблице клиентов является Entity
и представляется как таковой в вашем коде С#.
Используя шаблон репозитория, мы можем абстрагироваться от реализации кода доступа к данным, так что в будущем, если наш источник данных изменится, остальное наше приложение не будет затронуто. Далее нам понадобится CustomersRepository
в нашем Data Access Layer
, который будет включать такие методы, как Add
, Remove
и FindById
. Отвлечь любой код доступа к данным. Ниже приведен пример того, как вы достигнете этого.
public interface IEntity
{
int Id { get; set; }
}
public class Customer : IEntity
{
public int Id { get; set; }
public string FirstName { get; set; }
public string LastName { get; set; }
public DateTime RegistrationDate { get; set; }
}
public interface IRepository<TEntity> where TEntity : class, IEntity
{
TEntity FindById(int id);
void Add(TEntity entity);
void Remove(TEntity entity);
}
public class CustomerRepository : IRepository<Customer>
{
public Customer FindById(int id)
{
// find the customer using their id
return null;
}
public void Add(Customer customer)
{
// add the specified customer to the db
}
public void Remove(Customer customer)
{
// remove the specified customer from the db
}
}
Уровень доступа к данным находится между слоем данных и бизнес-логикой.
// ----------------------------
// Business logic
// ----------------------------
// ----------------------------
// Data access layer
// - Repository
// - Domain models / Business models / Entities
// ----------------------------
// ----------------------------
// Data tier
// - MySQL
// - MS SQL
// - SharePoint list
// - Excel
// - CSV
// - NoSQL
// ----------------------------
Бизнес-уровень
Бизнес-уровень построен поверх уровня доступа к данным и не касается проблем с доступом к данным, но строго бизнес-логики. Если одним из бизнес-требований было предотвращение заказов из-за пределов Великобритании, тогда уровень бизнес-логики справился бы с этим.
Уровень представления
Уровень презентации просто представляет ваши данные, но если вы не будете осторожны в отношении того, какие данные вы представляете, и какие данные вы позволяете размещать, вы ставите себя на множество головных болей по линии, что поэтому важно использовать модели просмотра, поскольку модели представления представляют собой проблему уровня представления, уровень представления не должен ничего знать о ваших моделях домена, он должен знать только о моделях представлений.
Итак, что такое View Models... Это просто модели данных, которые настроены для каждого представления, например, форма регистрации будет включать RegistrationViewModel
, отображая эти типичные свойства.
public class RegistrationViewModel
{
public string Email { get; set; }
public string Password { get; set; }
public string ConfirmPassword { get; set; }
}
Уровень представления также обрабатывает проверку ввода, поэтому, например, проверка правильности формата адреса электронной почты или совпадение паролей представляет собой проблему уровня представления, а не деловую проблему, и ее можно обрабатывать с помощью Data Annotations
.
public class RegistrationViewModel
{
[Required]
[DataType(DataType.EmailAddress)]
public string Email { get; set; }
[Required]
[DataType(DataType.Password)]
[Compare("ConfirmPassword")
public string Password { get; set; }
[Required]
[DataType(DataType.Password)]
public string ConfirmPassword { get; set; }
}
Причина, по которой важно использовать модели просмотра, заключается в том, что бизнес-модели относятся к бизнес-уровню, и они включают данные, которые должны оставаться конфиденциальными. Например, если вы должны были отобразить модель домена в ответе JSON, это разоблачит все данные пользователей, их имя будет их адресом, поскольку вы не будете избирательным в отношении того, что подвергается, а что нет, но используя все, что кажется, работает.
Здесь также следует указать, что существует разница между domain models
и entity models
. Там уже есть ответ, который будет намного подробнее здесь
Проблемы с поперечной средой
Я буду держать это сообщение:
- Управление исключениями
- Сопоставление моделей моделей с моделями.