Wrox Programmer Forums

Need to download code?

View our list of code downloads.

Go Back   Wrox Programmer Forums > C# and C > C# 2005 > C# 2005
Password Reminder
Register
| FAQ | Members List | Calendar | Search | Today's Posts | Mark Forums Read
C# 2005 For discussion of Visual C# 2005.
Welcome to the p2p.wrox.com Forums.

You are currently viewing the C# 2005 section of the Wrox Programmer to Programmer discussions. This is a community of tens of thousands of software programmers and website developers including Wrox book authors and readers. As a guest, you can read any forum posting. By joining today you can post your own programming questions, respond to other developers’ questions, and eliminate the ads that are displayed to guests. Registration is fast, simple and absolutely free .
DRM-free e-books 300x50
 
 
Thread Tools Search this Thread Display Modes
  #11 (permalink)  
Old December 24th, 2007, 04:52 AM
Friend of Wrox
 
Join Date: Jun 2003
Location: , , USA.
Posts: 1,093
Thanks: 1
Thanked 12 Times in 11 Posts
Default

Imar! I was just thinking about you! Hit a glitch of the 'way over my head' variety. But I should probably start a new thread for it. So it'll be on this forum called "Wrong Principal Object." Its CSLA related. Sure'ld appraciate any thoughts.

Bob

  #12 (permalink)  
Old January 2nd, 2008, 05:40 PM
Friend of Wrox
 
Join Date: Jun 2003
Location: , , USA.
Posts: 1,093
Thanks: 1
Thanked 12 Times in 11 Posts
Default

Hi Peter,

I had a chance to read the Fowler article and just have a couple of comments I’d like to share. Frameworks like CSLA built over the .NET framework provide several possible solutions to a few of the primary object design issues Fowler addresses.

His essential objection to the design of the types of distributed objects he discusses seems to be the:

"…essential point that any object that may be used remotely should have a coarse-grained interface, while every object that isn’t used remotely should have a fine-grained interface."

"If you base your distribution strategy on classes, you’ll end up with a system that does a lot of remote calls and thus needs awkward, coarse-grained interfaces."

Not so when you implement serializable, CSLA style mobile objects. When you do, you end up with a very different picture. You end up with:

- a distribution strategy based on classes and

- mobile objects that fully encapsulate all their business logic and data access logic, and can be passed by value (via serialization) to a remote process, and do their work in that process

- which limits remote calls

- to the four standard CRUD methods implemented in an elegantly designed, course-grained data portal router object anchored (MarshalByRefObject) to either a local or application server process (as determined by a configuration file setting).

That’s a mouth full!

This logical architecture can support any physical architecture you like. Hope I can clarify it a little.

The fine-grained, “normally” designed business objects are used remotely via serialization. If a client wants to, say, update a mobile business object it is working with, and the course-grained data portal object is anchored in a remote process, when the client requests the update by calling the data portal Update method, the edited mobile object is serialized and passed by value to that process. The remote process now has a copy of the edited business object it can work with locally, calling properties and methods (like an Update method) of the “smart” business object with no performance overhead. The anchored object instructs the mobile business object to update itself by calling the business object’s Update method (all data access code is encapsulated in the business object). The updated object is then serialized and returned - again by value - to the client. The client now uses the new copy of the updated mobile object.

The only performance hit was in copying the object across the network - using binary transfer which is 30% faster than transferring, say, a DataSet. Doing this of course requires that both machines have the .NET assembly containing the objects code installed, which can be accomplished by a variety of deployment strategies, including .NET deployment strategies.

Fowler states that a “…fine-grained interface doesn’t work well when it’s remote.” This is true only when the fine-grained interface is called from another process. The situation changes completely when the interface is transferred to the remote process, and does its work in that process, which is what .NET technologies enable. A course-grained, anchored interface running in a process with access to the database server still exists (the data portal) for minimizing calls from the client, but now the anchored object and the mobile object run in the same process, and the anchored object can invoke the data access methods encapsulated by the mobile object.

Another problem Fowler mentions that is overcome by .NET serialization is:

“You usually can’t send the domain object itself, because it’s tied in a web of fine-grained local inter-object references.”

When a .NET object is marked as [Serializable()] it and any other object referenced by it is serialized into the byte stream that gets transferred to the remote process. Problem solved (except for certain issues surrounding event handlers which are easily resolved).

The whole remote facade and data transfer object issue is also resolved, because a DOT is no longer required. A copy of the smart business object itself (actually its serialized state data) is sent to the remote process.

Thanks again for the article reference. I hope some of this is intelligible. I'm just thinking through CSLA and distributed programming issues a lot recently, and writing helps a great deal.

Best,

Bob









  #13 (permalink)  
Old January 2nd, 2008, 06:23 PM
Friend of Wrox
 
Join Date: Jun 2003
Location: , , USA.
Posts: 1,093
Thanks: 1
Thanked 12 Times in 11 Posts
Default

Then again, Fowler's remarks apply to CSLA and .NET to a degree, as well. The anchored object in the remote process is still a course-grained interface required by the system, and is really the only object that is called remotely by the client. And, yes, I suppose it is a little awkward in certain respects. And the fine-grained interfaces of the business objects aren't "used" remotely, in the sense of being called by the client. Technically, they are "used" locally by the anchored object, and in a process that is remote only relative to the client process. So Fowler is perfectly correct when he says that a "…fine-grained interface doesn’t work well when it’s remote", if this is taken to mean: doesn’t work well when its called directly by the client, which is, I think, how it should be taken.

What .NET introduces is the concept of designing business objects with "normal", fine-grained interfaces that can do there work in a remote process without the client having to know about them "by reference", with all the performance overhead and network latency that arrangement would entail. Or something along those lines.

Bob

  #14 (permalink)  
Old January 2nd, 2008, 10:55 PM
Friend of Wrox
 
Join Date: Jun 2003
Location: , , USA.
Posts: 1,093
Thanks: 1
Thanked 12 Times in 11 Posts
Default

Last thought and I'll give it a rest.

In the final analysis, I'd have to say the three statements of Fowler's I was consideriing:

"…the essential point that any object that may be used remotely should have a coarse-grained interface, while every object that isn’t used remotely should have a fine-grained interface."

"If you base your distribution strategy on classes, you’ll end up with a system that does a lot of remote calls and thus needs awkward, coarse-grained interfaces."

“…fine-grained interface doesn’t work well when it’s remote.”

can all be fairly asserted of CSLA. Even though the objects copied to the remote process may have a fine grained interface, the anchored remote object, the course-grained data portal, can only call the mobile object's create, read, update, and delete methods anyway, leaving one with the course-grained remote interface Fowler is describing.

Anyway, it has been helpful to think this stuff through out loud.

Bob


  #15 (permalink)  
Old January 2nd, 2008, 10:58 PM
planoie's Avatar
Friend of Wrox
Points: 16,481, Level: 55
Points: 16,481, Level: 55 Points: 16,481, Level: 55 Points: 16,481, Level: 55
Activity: 0%
Activity: 0% Activity: 0% Activity: 0%
 
Join Date: Aug 2003
Location: Clifton Park, New York, USA.
Posts: 5,407
Thanks: 0
Thanked 16 Times in 16 Posts
Default

Bob,

I'm glad you followed up with yourself, LOL :). I was formulating questions as I read the first longer post, then you pretty much answered them.

Yes, I agree with you. To reiterate, as it helps me understand it as well: The problem is not when we use objects the way you describe, where an object is wired across and a single (possibly complex) operation happens in the remote process (this being essentially a coarse-grained interface). The problem is when we use the members of the fine-grained interface across the process boundaries. What we use will depend entirely on the class design. So, yes, if your objects naturally have a course-grained interface, they are much easier to move out-of-process (given other conditions). Fowler's main point though on that is that in-process classes should be fine-grained and thus not so portable.

This is a very interesting topic. I haven't really worked with remoting a whole lot, so I can't say much from experience. I've been dabbling with it but I'd like to get more proficient. This will certainly help.

-Peter
  #16 (permalink)  
Old January 3rd, 2008, 01:52 AM
Friend of Wrox
 
Join Date: Jun 2003
Location: , , USA.
Posts: 1,093
Thanks: 1
Thanked 12 Times in 11 Posts
Default

LOL. :) Just a little recursive posting.

One caveat. In finally asserting that CSLA fits Fowler's "local fine-grained object interface/remote coarse-grained object interface" model, I am in no way implying that CSLA is an "Errant Architecture" (Fowler's title). I actually have no idea how it, or frameworks like it, perform in a physically distributed environment. I've also only dabbled with this stuff, on a laptop using a local installation of IIS as a remoting host. I've made processes - not machines - swap objects. Can't say enough, though, about CSLA as a tool for learning the .NET "subsystems" (remoting, serialization, threading, reflection, security, COM+ serviced components). There's really no way to grasp how seamlessly these technologies support and collaborate with one another short of diving into a .NET distributed application framework and poking around.

Best,

Bob

 


Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off
Trackbacks are Off
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
.NET Remoting and SQL Server 2005 express Bob Bedell SQL Server 2005 1 December 21st, 2007 10:37 AM
Connecting to SQL Server 2005 Express Locally GM_Access BOOK: Beginning Access 2003 VBA 1 August 7th, 2007 06:34 PM
SQL SERVER 2005 STANDARD (not express) proslambano BOOK: Beginning ASP.NET 2.0 BOOK VB ISBN: 978-0-7645-8850-1; C# ISBN: 978-0-470-04258-8 8 January 8th, 2007 08:55 PM
SQL Server 2005 Express Problem asped_man BOOK: Beginning ASP.NET 2.0 BOOK VB ISBN: 978-0-7645-8850-1; C# ISBN: 978-0-470-04258-8 3 November 29th, 2005 05:07 AM



All times are GMT -4. The time now is 02:49 PM.


Powered by vBulletin®
Copyright ©2000 - 2019, Jelsoft Enterprises Ltd.
© 2013 John Wiley & Sons, Inc.