Платформа объекта в многоуровневых архитектурах

Question

Платформа объекта в многоуровневых архитектурах

Недавно я прочитал статью "The Entity Framework In Layered Architecture", и там записан, мы можем отправить EF-объекты клиенту через WCF. Но во многих потоках на людях Stackoverflow говорят, что ПОСТЕПЕННО (DTO) - объекты должны использоваться, когда мы используем WCF. И у меня есть некоторые вопросы.

Почему Microsoft добавляла, что DataContract приписывают EF-объектам? Microsoft хотела, чтобы мы использовали эти объекты везде в наших приложениях? Или это только для очень простых приложений и для быстрой разработки?
Если я использую ПОСТЕПЕННО-ОБЪЕКТЫ, я должен создать автоматические сгенерированные EF-объекты, ПОСТЕПЕННО-ОБЪЕКТЫ и после того, как это пользуется какой-либо библиотекой отображения между ними? Или я должен использовать только ПОСТЕПЕННО-ОБЪЕКТЫ во всех компонентах моего приложения?
Если у меня уже есть свой объект собственного дела, который имеет некоторые методы, и он должен быть отображен на ПОСТЕПЕННО объекте, на котором слое я должен преобразовать ПОСТЕПЕННО ОБЪЕКТНЫЙ в свой объект (например, у меня есть слой персистентности, слой бизнес-логики, уровень служб (WCF), слой предъявителя (клиент, используйте WCF), уровень UI)? Или я не должен делать такие свои собственные объекты?

Заранее спасибо

6

c# .net entity-framework poco

задан Pavel Belousov 16 July 2010 в 05:58

2 ответа

Вы можете иметь рукописные объекты POCO и полностью отделить их от уровня сохраняемости. SDReys прав, используя сгенерированные объекты EF, поскольку ваша модель вонючая.

Вот приблизительный макет простой модели POCO и контекст для ее поддержки.

public class MyApplicationContext : ObjectContext, IMyApplicationContext {   
    public MyApplicationContext() : base("name=myApplicationEntities", "myApplicationEntities")  
    {
  base.ContextOptions.LazyLoadingEnabled = true;
        m_Customers = CreateObjectSet<Customer>();
        m_Accounts = CreateObjectSet<Account>();
    }

 private ObjectSet<Customer> m_Customers;
 public IQueryable<Customer> Customers {
        get { return m_Customers; }
    }
 private ObjectSet<Account> m_Accounts;
 public IQueryable<Account> Accounts {
        get { return m_Accounts; }
    }

 public Account CreateAccount(Customer customer) {
  var account m_Accounts.CreateObject();
  account.Customer = customer;
  return account;
 }
 public Customer CreateCustomer() {
  return m_Customers.CreateCustomer();
 }

 public void AddAccount(Account account) {
  m_Accounts.AddObject(account);
 }
 public void AddCustomer(Customer customer) {
  m_Customers.AddCustomer(customer);
 }
}

public class Account {
    public int Balance {get;set;}
    virtual public Customer{get;set;}
}

public class Customer {
    public string Name {get;set;}
    virtual public List<Account> Accounts{get;set;}
}

1

ответ дан 17 December 2019 в 06:59

Другие вопросы по тегам:

c# .net entity-framework poco

Похожие вопросы:

score 3 · Accepted Answer

1.Почему Microsoft добавила атрибут DataContract к EF-существам? Разве Microsoft хочет, чтобы мы использовали эти объекты везде в наших приложениях? Или это только для очень простых приложений и для быстрой

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

2.Если я использую POCO-объекты, должен ли я создавать автоматически генерируемые EF-сущности, POCO-сущности и после этого использовать какую-либо библиотеку отображения между ними? Или я должен использовать только POCO-объекты во всех

Вы можете использовать POCO-объекты внутри вашего сервисного слоя, чтобы отвязать его от любых нижележащих слоев (см. Automapper, чтобы покрыть расходы на отображение Entity-DTO). Но вы все равно можете использовать автогенерируемые EF-сущности среди слоев данных и бизнеса в вашей архитектуре. Просто постарайтесь не полагаться на EF-специфические особенности вашей сгенерированной доменной модели в других слоях, отличных от слоя данных. для облегчения перехода на другой ORM-фреймворк.

Если у меня уже есть своя бизнес-сущность, у которой есть некоторые методы, и если у меня уже есть сущность, у которой есть некоторые методы, и она должна быть отображена на объект POCO, на на каком уровне я должен преобразовать POCO-объект в мою сущность (например, у меня есть уровень персистенции, уровень бизнес логический слой, сервисный слой (WCF), слой ведущего (клиент, использующий WCF), UI слой)? Или мне не стоит создавать такие

Service layer http://msdn.microsoft.com/en-us/library/ms978717.aspx. Вы будете использовать вашу доменную модель прозрачно среди серверного уровня (persistence, business, service и presenter layers) вашего приложения, и единственный слой, который потребует от вас DTO mapping - это слой service, см. вопрос 1. (дополнительно, если вы используете ViewModels внутри вашего presenter layer - хорошая идея - вы потребуете использовать POCOs-mapping в presenter layer тоже).