Login | Register   
LinkedIn
Google+
Twitter
RSS Feed
Download our iPhone app
TODAY'S HEADLINES  |   ARTICLE ARCHIVE  |   FORUMS  |   TIP BANK
Browse DevX
Sign up for e-mail newsletters from DevX


advertisement
 

A Pure Object-oriented Domain Model by a DB Guy, Part 4 : Page 7

This is the fourth in a series of articles by Jimmy Nilsson on a new architecture for enterprise applications in .NET. The new architecture is purely object-oriented, while still focusing on roundtrips and the data access code to get good performance.


advertisement
Interface or Not
In part 3 I accessed the Application layer class directly, without custom interfaces (Bridge pattern [10] or Separated Interface pattern [2]).

The way I see it the Bridge and Separated Interface patterns are more or less what you get when you declare an instance as an Interface instead of as a class.

Working directly with the Application layer classes is easiest, and I also think there is otherwise a risk of finding that I have to create one interface per Application layer class. Been there, done that.



On the other hand, if you are going to talk with the Application layer over a remoting boundary, then the best practice is to use custom interfaces only [11]. One good thing about this is that you only have to distribute an assembly of interfaces to the consumer and not the assembly with the Application layer code itself. Plus, the added complexity is completely encapsulated by the Consumer Helper layer.

My friend Enrico Sabbadin [13][14] had this to say about only using custom interfaces when talking over a remoting boundary:

Watch out, this applies to SAOs only!

As you know remote objects can be registered in two ways: Client Activated Object (CAO) or Server Activated Object (SAO). SAOs can be registered as singletons or single calls.

If your object resides in assembly A and implements an interface defined in assembly B AND the object is registered as an SAO, you can get a reference to it using the Activator.Getobject function having only the interface (assembly A) deployed at the client side.

This does not apply to CAO. GetObject can't be used for CAO. And don't be fooled by the Activator.CreateInstance overloads which get an assemblyclassname and an activator attribute where you put the remote URL. This does let your client code be unaware about the class type, BUT the class type has to be available to the runtime on the client side.

For instance the code below (client side) will fail at the Activator.CreateInstance line unless the assembly where CaObject.mycao resides is available to the client process.

Dim url As New _ Activation.UrlAttribute("tcp://arrakis3k:8082/Myapp")

Dim ff(0) As Object

ff(0) = url

Dim s As ObjectHandle = _
Activator.CreateInstance("caobject", _

"CaObject.mycao", ff)

Dim ggg As Imyint = CType(s.Unwrap(), Imyint)

If Not RemotingServices.IsTransparentProxy(ggg) Then



Comment and Contribute

 

 

 

 

 


(Maximum characters: 1200). You have 1200 characters left.

 

 

Sitemap
Thanks for your registration, follow us on our social networks to keep up-to-date