Back to the 2-tier?

Back to the 2-tier?

• Subramaniyan

  I don't see why you'd need to manage your own concurrency.
  
  class DAL // connects to the database,
  {
     public static var FooTable = from c in db.FooTable; // just aliases a table in a particular database
     public static var BarTable = from c in db.BarTable where ..; // no projection
     public static var BazTable = from c in db.BazTable where .. select ..; // full query specified
  }
  
  in GUI:
     fooControl.DataSource = from c in DAL.FooTable where .. select ..;
     barControl.DataSource = from c in DAL.BarTable where .. select ..;
     bazControl.DataSource = DAL.BazTable;
  
  .. at least, that's what makes sense to me.  (I *really* want that x64 version of the compiler..)
  
  Remember that you're constructing a description of the query -- not performing the query itself.  You should be able to push the final projection into a higher layer, or just store a static description of a complete query (which is all you get from the "from .. where .. select" syntax) in the DAL. 
  
  This is analogous to using the DAL to store the SQL strings, which you then access by name to perform the queries -- the difference being, of course, that you now have access to a smart enumerator that knows how to talk to the database and return smart objects that know how to manage concurrency, rather than having to create a DataReader to get an enumerator that returns dumb objects.
  
  I realize that the idea of delayed execution is fairly new to most people, but it's something that MS has tried on various occasions to reiterate.
  
  
  

• Peter Huang - MSFT

  I admit this code looks very efficient, but only in a C/S scenario.
  
  How would delayed execution work if you're not in C/S scenario, but need to call a webservice for retrieving your data, and also a webservice for updating your data

  
  

• JohnCNTS

  Inside each SOA 'node' there is business logic that may need to interact with a database.  That's where you use DLINQ.  You may end up desiging entities that also act as messages, but its likely that you won't.  The entities usually just describe your persisted data model. You use other object definitions for the messages. Transitioning from data model to messages is easy since you can simply construct the messages as part of the query expression.
  
  

• Matthew Morrow

  If you're storing in a session, you use the state server.  If it's something that's in viewstate, you re-query the database (or re-load from state server), and then the changes are applied as part of the viewstate load.  In any case, you just call the Update() and It Does The Right Thing.
  
  Re CRUDdy web services -- generally viewed as a bad choice in design.  Having lived for the past year-and-a-half with that choice, myself, I have to agree.  Focus your web services on operations, not mechanics.  Otherwise you have a very chatty, and not particularly useful, web service that doesn't buy you anything over accessing the database directly.
  
  
  

• holstad

  Keith,
  
  

  I would forward the idea, perhaps, that we've not gone from 3 to 2, but from 3 to 4:  presentation -> query -> access -> store.

  
  
  This is the layering advocated by Domain Driven Design. In some systems you need a service layer between the client and the query (Repository classes).
  
  

• Hiran55681

  If you were willing to create known types for the messages, you could just hold a reference to the entity in memory, and expose only select properties backed by the entity as part of the message interface.
  
  In this way, the projection changes from
  
  select new { foo = c.foo, bar = c.bar }
  
  to
  
  select new Message(c)
  
  where Message is defined:
  
  class Message
  {
     private EntityType _entity;
     public Message(EntityType entity) { this._entity = entity; }
     public FooType foo { get { return entity.foo; } }
     public BarType bar { get { return entity.bar; } }
  }
  
  Another benefit is that you don't have to keep track that all the queries conform to changes in message schema: you let the message class adapt entities in a central location.  It'll also hold the reference to the original entity.

  
  
  

• Bill Barnett - MSFT

  As I understand it DLINQ will, in a C/S scenario, do optimistic concurrency by itself without me needing to do anything.
  
  When I have an 3-tier scenario where GUI and applicationserver are seperate I need to manage my own concurrency right So I use either viewstate, or I need to expand my DTO's to include some form of versioning.
  
  
  Regarding the CRUDdy web services. We're getting off topic, but it is interesting anyway... I agree that CRUDdy SOA is bad, but I feel that in a 3-tier scenario not every web service is an enterprise service. A lot of web services are nothing more than fancy RPC's into your application server.
  
  Example: We have an application where we sign up participants to a pensionfund. There are two ways to do this:
  a) A 'real' enterprise service where an XML document with all necessary information about this person is entered
  b) A 'cruddy' service where the person is already in the system, the user has selected this person and is only adding a record to the employment history of the person
  
  The first service is actually called from multiple systems, the second one only from our own GUI and is very CRUDdy. We've set them both up to have fullfledged XML documents as parameters and be very reusable, but reality is that (b) will never be called from another system and looking back at the project most people consider (b) to over-engineered.
  
  

  
  

• prashant_victory

  Nagymester wrote:

  It seems to me that Dlinq with this nice new feature of Entity = Class is good for a Client/Server scenario only. How would it worlk in a SOA at all

  
  
  Well, let start by asking whats your definition of SOA I like this one:
  
  A service-oriented architecture is a collection of services that communicate with each other. The services are self-contained and do not depend on the context or state of the other service. They work within a distributed systems architecture.
  
  I don't quite see then how we're still not building services that communicate with each other; They can certainly be indepedent of each other in terms of state and context. I don't see anything here that causes them not to work in a DSA. So I'd be interested in understanding how you DLINQ is at odds with SOA.
  
  Where I have a problem with DLINQ is that it requires moe explicit knowledge of physical structure of the database than before. I've still not written code that calls a stored procedure or view, for example. I can see how a view might work easily enough, but procedures are another ball of wax.

  
  
  

• Helloooo

  Well, you're in charge of the actual layer, still, I think.  Metal just creates object stubs representing, for example, tables.  There's every reason to think one could create a method representing a sproc, which returned a collection of strongly-typed rows -- I don't think Metal would be the likely avenue for that, given that a sproc *could* return arbitrary schema depending on inputs.  So, in all that, Metal is just one tool to create the middle data layer -- you could just as well expose it differently, and (D)LINQ could still be applied.  In the current preview, of course, it may be more difficult, but it *is* just a preview.
  
  I would forward the idea, perhaps, that we've not gone from 3 to 2, but from 3 to 4:  presentation -> query -> access -> store.
  
  
  

• ianic

  The Dlinq needs very tight Database connectivity; on the other hand Business Entity based programming by Classes needs state – full programming, which is Client – Side programming. So Dlinq is clearly Client/Server paradigm.
  By the way sometimes it is not bad at all.
  I think that for the SOA world more appropriate Xlinq, since the XML is clearly message format and Xlinq makes it easy to work with XML on a very intuitive way.
  Nowadays the Datasets are representing the Business Entities in a Microsoft SOA world, because easily transferable between tiers; on the other hand they are proprietary Microsoft constructs. 

  
  

• Chear

  Matt,
  
  

  Transitioning from data model to messages is easy since you can simply construct the messages as part of the query expression.

  
  
  Yes, the projection is great for this. Now what we need is a way to apply messages back the domain model. Does the expression tree keep any knowledge about the source of the projection so I can work backwards from the projection and update the in memory entities (updatable projections)
  
  

• tcs122499

  This link talks about the principle of service design: Patterns and Anti-Patterns  http://msdn.microsoft.com/library/default.asp url=/library/en-us/dnbda/html/SOADesign.asp
  
  Hope it helps

  
  

• Mythox

  I admit that the thread has lost me a little, but I do get the feeling that the remoting issue has not been solved with (D)LINQ just yet.
  
  My typical web application would look like this:
  
  Web GUI, calling web services which in turn go to the database.
  
  So a lot of my typical services will be very CRUD based.
  
  AddOrder(..)
  GetOrder(..)
  UpdateOrder(..)
  
  Now my web services are stateless, in fact, I may have a farm.
  How will I reconnect my Order object to the entry in the database when I'm calling UpdateOrder(..)
  
  If I wrote some OR-mapping for myself I'd probably add a 'VersionID' field to every database table (thus every object). How will LINQ do this for me
  I understand that in client/server scenario there is way of reconnecting, but not in a remoting scenario.
  
  

• aNeves

  See.. every time I think I'm being clever, I discover someone else wrote a book on it.
  
  Mild vindication, but it doesn't get me closer to ruling the world ;)
  
  
• Back to the 2-tier?