locked
Partial Classes, BLLs and ADO.NET Data Services RRS feed

  • Question

  • One of the strengths of the Entity Framework is building out the BLL through partial classes and additional classes.  As far as I can tell the ADO.NET Data Services only supports the root classes coming straight from the EF. 

    Is there any good way that I can extend the EF into a working BLL and still use Data Services?

    I can think of 3 work-arounds, but they all bite:
    • build and use use two separate service interfaces and have the client use one or the other depending on the complexity of the request/response
      • straight table (actually Entity) reads and writes through the DS interface
      • any reads/writes requiring BLL type manipulation goes through a hand coded service layer
    • Build a thick client with the BLL at the client (which is not only ugly architecturally, but likely requires a lot more work).
    • Listening to read/write events at the framework layer and then back filling (which I haven't tested) with a second request/response.
    Am I missing something? 
    Monday, June 9, 2008 6:05 PM

All replies

  • I've been researching some more -
    http://mtaulty.com/CommunityServer/blogs/mike_taultys_blog/archive/2007/12/19/10031.aspx
    http://blogs.msdn.com/astoriateam/archive/2008/04/10/iupdatable-ado-net-data-services-framework.aspx

    Is that the right path?  Does that mean that I should be decorating my partial classes and full classes with an iqueryable and/or iupdatable interface to get access to them? 

    Is there an full implementation example that someone can point me to, hopefully using Beta1 bits?
    Tuesday, June 10, 2008 8:04 PM
  • Can you give an example of what you want to do in a partial class and how you want that exposed at the data services layer?  I'm not sure I'm following exactly what you want to accomplish.

    Wednesday, June 18, 2008 4:41 AM
  • Hi Mike,

     

    Sure. To start, we are building a combination of WPF clients, with some of the same code base used for ASP.net presentation and Windows Services (for collecting datafeeds). 

    Desired architecture is thin clients for presentation -- thick server doing business layer and db access -- db.

     

    Here are a number of the more interesting examples of what we do in a business layer:

    • a change tracking listener that listens to certain tables or fields for inserts/updates and then logs the pre-update and post-update values, who changed them and when.
    • spooling off an insert/update/delete to a couple legacy slave tables in non EF databases.
    • sophisticated search activities (e.g., identify that the typed search word is a company, not a drug or a person's name, so that I can then request a series of sub-search results based on it being a company that was searched for).
    • triggering and logging a phone call from a VOIP pbx system upon a button click, which I'd rather initiate from a server than from the client (while fully realizing that the current purpose of DS is not a universal client-server pipe)
    • Triggering workflow rules

    There are many other, more mundane examples too.

     

    As you probably know, we can take an existing class in the EF layer and add a partial class (e.g., public partial class Company {}) and then add the constructors, methods, fields and properties, and access them from everywhere else as if they were part of the class itself.  This is the A-ticket ride of the EF world - it saves years of our lives.

     

    What I want is simple:  I want the DS layer to expose the partial class extensions, instead of just the base classes.  I can understand where a bad partial implementation of an override would break something you rely on, but let it break with a message that it broke.  I don't want to need to implement a whole iqueryable/iupdatable interface for an addition of a derived field used in a select statement.

     

    To take it a step further, for those classes that I add that are purely BLL classes with no EF backing, I want the DS layer to expose them without me needing to write the interface, as long as I decorate them correctly.  Have the DS fill in all the iqueryable/iupdatable minutiae that I really don't want to need to learn.

     

    I find the 1.0 specific Query Interceptors, Change Interceptors and Service Operators to be non-starters because if such functionality is important enough to sit on the server, it is important enough to be in a BLL so that it is accessible through the other interfaces that we're building on the same code base.

     

    Is there any way to expose partial classes? If the only access for non-EF data is iqueryable/iupdatable, can I do it for partial classes?  Do I just add partial classes, knowing that they aren't accessible and then use Query Interceptors and the like as wrappers?  How do I best accomplish my goals?

     

    Thanks,

    Peter

    Monday, June 23, 2008 11:37 PM
  • Hi.  This is great topic.  Modifying partial classes i think is not advisable on EF? (Correct me if i am wrong on this; i'm new on LINQ) Since, if there are changes on your model at the backend you would loose your changes on the designer when you are going to update.  However, as of June CTP; we could inherit the whole model?  By this i think we could manipulate (add contructors etc).

     

    I haven't tested this.  But I want to do it because I think I have to create a default values for every new record that will be created on a certain model.

     

    Monday, June 30, 2008 2:08 AM
  • Hi Jojo,

     

    No, you can add a parital class in the same namespace as the EF model referencing an entity object and, because it's a separate file, even if you alter the EF model or rebuild it from scratch, the partial classes still remain.

     

    Normal code referencing the namespace can't tell the difference between the EF model and the extensions.

     

    Peter

    Wednesday, July 9, 2008 6:16 PM
  • I subscribed to this thread. I will love to hear more about this topic. At my company we are waiting for future releases of EF + ADO Data Services + Silverlight to move to this new very productive and amazing "framework" that Microsoft is creating.

    Thanks
    Wednesday, July 9, 2008 8:56 PM
  • Hi Marbles,

     

    Did you mean that in creating the partial class it would be on a separate physical class or filename?

    not on Model.Designer.vb right?

     

    Tuesday, July 15, 2008 5:11 AM
  • Yes John.  That's right.

     

    Friday, July 18, 2008 8:18 PM
  • Mike, given the popularity of this topic, it seems like a question other people must have, but no one from MS has commented other than "tell me more...".  Could you or someone else at MS weigh in with some practical advice about how we should go forward?

     

    - Peter
    Friday, July 18, 2008 8:42 PM
  • Hi,

    I've also asked (essentially) the same thing on another thread but am also keenly watching this one.

     

    Matt

    Saturday, July 19, 2008 10:13 AM
  • Is there any news on this issue lately?


    Thanks,
    Koen
    Monday, September 29, 2008 6:50 AM
  • I gave up and decided not to use the ADO.Net data services.

    I concluded it's OK for only the most very basic and small scale scenarios.

     

     

    Monday, September 29, 2008 8:09 AM
  • Sorry for my late reply on this thread.  In V1 of Astoria we effectively have two ways for a data service author to provide us a data model that we will use to generate the REST service layer for you.  The first is by giving us an EF ObjectContext instance.  This method is designed to make it easy to take relational data and expose it (after appropriate security checks, etc) as a REST-based service.  Extensibility by adding partial classes, etc can be done; however, we require all extensions to in turn be added to the EF mapping files (CSDL, MSL, SSDL).  Adding such things to the mapping files can be non trivial today and the tooling does not yet support this so you would be in the business of hand-editing XML. 

    The second approach to define the data model used by a service is to use our "reflection service provider" hookup.  This effectively means you give the data services runtime a set of .NET classes which represent your data model, an IQueryable implementation for your data source and an System.Data.Services.IUpdatable implementatino for your data source you can a data service created over (more or less) an arbitrary set of .NET classes.   How to create a "reflection provider" is desribed in this whitepaper: http://msdn.microsoft.com/library/cc907912.aspx (see the topic "Creating a data service from any data source").  

    All that said, we understand going the route of writing a provider as noted above can be a fairly large task and if all you wanted to do was add a few entities to what was provided by an EF Object Context this can be a bit of overkill.  We have received this feedback and are in the process of exploring how we can better support this scenario.  We are currently looking at ideas from a simple way to inject new entities all the way to ideas such as a new provider layer (to complement the others, not as a replacement) which smells like a BLL. 

    On a seperate note: we are now the ADO.NET Data Services bits in MSFT data centers backing such services as Windows Azure Table Storage as a way to validate the scalability of our current any future provider models and overall REST services implementation.


    I hope that helps...

    -Mike
    Data Services Program Manager

    ps. an additional extension point in data services V1 is Service Operations (also discussed in the above link).  These give you far less control than creating your own provider layer, but are nice for some simple extension scenarios. 
    Wednesday, January 14, 2009 5:17 PM
  • No no we dont tell you the answer, you have to pay for this kind of support
    --------------joking aside

    @ Mike Flasko

    You are naughty developer ^^ changing the mapping files is so dirty. I like the sound of it.

    @ Original Poster

    I am not sure if you are over complicating things. Is that your implementation so "volatile" (which i mean the requirements will always change and the solution will evolve continuously) that you require so much softness on your architecture?

    Daniel Portella Blogger from hell http://undocnet.blogspot.com
    If this post answers you question please mark as the answer.

    Daniel Portella - http://undocnet.blogspot.com - This posting is provided "AS IS" with no warranties, and confers no rights.
    Wednesday, January 28, 2009 8:54 PM
  • No no we dont tell you the answer, you have to pay for this kind of support
    --------------joking aside

    @Everyone

    May be it is possible to create one IQuerable and one IUpdatable classes that will do what ever you want we could make the use of some custom attributes etc to make the peon work.

    As a note please read the definition of Ado.Net Data Services posted by pablo castro.


    Daniel Portella Blogger from hell http://undocnet.blogspot.com
    If this post answers you question please mark as the answer.

    Daniel Portella - http://undocnet.blogspot.com - This posting is provided "AS IS" with no warranties, and confers no rights.
    Wednesday, January 28, 2009 9:00 PM
  • Hi Mike,

    Wow.  Thanks for remembering. 
    Hi Dan.   Interesting idea about building a community base class.

    I ended up accepting Astoria V1 for it's limitations;  I used 2 parallel access methods to my data services.    For those activities requiring a BLL on the server I built a WCF interface.  Simple CRUD goes through ADO.net Data Services.  My audit tracking solution approach is far weaker than it should be if I could do it with extensions and/or partials like I'd like to.  I long ago decided that the efforts involved in extending the server side to allow generalized Astoria access were too much of a hassle.

    I think what you've done with V1 is great and I use it, despite any pain around the edges, but I have to say that in general, it seems like this project, for all its greatness and worth, has suffered from an extreme case of not being in touch with the rest of Microsoft on how to do basic integration with the rest of the stack.  In some respect, my difficulty 9 months ago with figuring out how to use this in the big picture has carried through to today, but is now reflected in other ways that was evident very recently.

    I was actually kind of appalled that when I attended a popular all-day Microsoft WPF event a couple weeks ago and asked all the Microsoft reps (primarily big name bloggers in the WPF and VB space -- not that I do VB :) ) about how to integrate ADO.net data services (which have been out for a year) and MVVM (which has been promoted as the WPF architectural approach for a couple years now) no one presenting or representing MS had even tried to mix the two, let alone knew how to do it. 

    I understand that every development effort within a company comes from the brilliance of the base developers who each come from separate worlds, but this is kind of an extreme case of non-communication between your team and those who would best promote it.  It's like the data team and the WPF team work at completely different companies, when in reality, developers need both to work together.

    It would do a great favor to those of us in the community who are actually trying to use your technologies in a production environment for you ask the dev relationship people (not the SQL guys but the Client side guys) within Microsoft to come over to build you a basic demo using the technology and applying their current architectural principles.   As a direct benefit to your project, as you're trying to figure out where you want to go with this next build, it will help you greatly to smooth out the pain points that we developers have.

    If you do setup these meetings and can get some practical solutions, please let us know.

    Thanks,
    Peter
    Wednesday, February 11, 2009 11:57 PM
  • Right completely undertand your fustrations and glad that you have decided to go for it, so did I, I not alone in there. 

    Yes i have put some thought into it, I have done a lot of helper classes and a small framework to work around the issues and short falls of astoria, it may be a good idea to combine into one community framework. I have some solution of mine with partial object tracking on the client side, i done everything besides tracking changes in collections, mainly because i have not had the time to write my own collection yet that supports change tracking.



    Daniel Portella - http://undocnet.blogspot.com - This posting is provided "AS IS" with no warranties, and confers no rights. If this post is answered your question please mark as the answer and if it is helpful do like wise.
    Thursday, February 12, 2009 12:17 AM