3

We are developing a 3-tier application with a WPF client, which communicates through WCF with the BLL. We use EF to access our database. We have been using the default EntityObject code generator of EF, but had lots of problems and serialization issues when sending those object through the wire, and when processing and reattaching them in the BLL.

We are about to switch to the POCO template, and rewrite the data access and the communication parts of our app (we are hoping to have a cleaner architecture and less "magic code" that way.

My question is whether it is a good idea to reuse the POCO classes on the client side? Or should we create separate DTO classes? Even if they would be identical to the POCO entity classes? What are the pros/cons of the two approaches?

Mark Vincze
  • 7,737
  • 8
  • 42
  • 81
  • 1
    check this answer as well about how to avoid to bring EF entities dependencies to layers above DAL: http://stackoverflow.com/questions/7474267/mvc3-and-entity-framework/7474357#7474357 – Davide Piras Oct 28 '11 at 09:35
  • Have you checked out some of the "Related" questions? There has been a lot of discussion on this topic before. Refer http://stackoverflow.com/questions/725348/poco-vs-dto and http://stackoverflow.com/questions/3779508/what-is-the-best-practice-for-sending-data-to-the-client-poco-or-dto – Jagmag Oct 28 '11 at 09:36

3 Answers3

3

Definitely use DTOs + AutoMapper. Otherwise you'll have tons of problems with DataContractSerializer while using WCF due to circular dependencies (especially problematic with navigational properties). Even though you may omit DTOs initially, you'll be forced to used them later on due to problems mentioned above. So I would advice using proper DTOs for each tier.

Also your tier specific models will carry different attributes. You may also need to modify (i.e. specialize) the data that you carry up in each tier. So if your project is large enough (or have the prospect to be so), use DTOs with proper naming and place them in proper locations (i.e. not all in the same assembly).

Teoman Soygul
  • 25,584
  • 6
  • 69
  • 80
  • Is this your advise even if in my case the DTO classes would be identical to the POCO classes? So basically I would start developing the app by creating a T4 template to generate the DTOs from the POCOs. – Mark Vincze Oct 28 '11 at 10:24
  • 1
    Yes that is my advice since it will save your from tons of headache as the project gets bigger. Also AutoMapper will simply save you from all the manual mapping hassle. If you're very confident with your DataContractSerializer knowledge, you can still use POCO's but you'll need to do lots of adjustments. – Teoman Soygul Oct 28 '11 at 11:25
2

Now i work on similar issue. I have done next:

  1. Create next assemplities:

SF.Contracts - that just defined ServiceCotnracts and DataContracts. Obvious all datacontracts may be used like POCO classes in EF (but i dont use t4 or other generator - all POCO classes and DataContext are written manualy, because i need to use very bad database). SF.

SF.DataAccessObjects - in this assemlity i implement my edmx and DataContext. SF.Services - implementation of WCF Services.

So, a large numbers of select WCF method have next signature and implementation:

        public List<Vulner> VulnerSelect(int[] idList = null, string[] navigationPropertiesList = null)
    {
        var query = from vulner in _businessModel.DataModel.VulnerSet
                    select vulner;

        if (navigationPropertiesList != null)
            navigationPropertiesList.Select(p =>{query = ((ObjectQuery<Vulner>)query).Include(p);
                                   return true; });
        if (idList != null)
            query = query.Where(p => idList.Contains(p.Id));

        return query.ToList();
    }

and you can use this method like this:

WCFproxy.VulnerSelect(new[]{1,2,3},new[]{"SecurityObjects", "SecurityObjrcts.Problem"});

so that, you have no problem with serrialization, navigation properties etc. and you can clearly indicate which NavigationProperties must be load.

p.s.: sory for my bad English :)

Community
  • 1
  • 1
Sergey Shulik
  • 950
  • 1
  • 9
  • 24
  • Thanks for the answer. In this example, the Vulner class is both your DTO which goes through WCF and both an entity class which EF manages, right? – Mark Vincze Oct 28 '11 at 10:23
  • Yes? you right. EDMP mapped my VulnreTable from DB to this POCO class, and that class used like DataContract on WCF service. – Sergey Shulik Oct 28 '11 at 10:25
1

I'd say use DTOs.

Circular dependencies and large object graphs can be a serious problem causing either errors or far too much serialised traffic. There's just way too much noise on an ORM controlled object to send it down the line.

I use a service layer to access my domain objects and use LINQ extensively, but I always return DTO objects back to the client.

iandayman
  • 4,357
  • 31
  • 38