about business object 's dependency

about business object 's dependency

Old forum URL: forums.lhotka.net/forums/t/6000.aspx


Evan posted on Tuesday, December 16, 2008

I am a newbie to csla, and i have a question.

As i read from the book, the business object can also be put on the client, then if the business object need some server's liberary, how can i get the library on the client?

Thanks.

tmg4340 replied on Tuesday, December 16, 2008

If you deploy your business-object library to the client, then any dependencies must be deployed to the client as well.  So, if your business object utilizes code from a "server library" on the client, then that library must be deployed to the client as well.

Note that I said "on the client".  If you are using the remote DataPortal feature, and your server-library code is only utilized in your DataPortal methods - and you haven't marked those methods with the RunLocal() attribute - then the server library does not have to be on the client with your business-object library.  It does have to be deployed to whatever machine is hosting your remote DataPortal.  But the DataPortal methods within your BO are only used by the DataPortal.  So if you set up your CSLA configuration to use a remote DataPortal implementation, you might not need your server library deployed to your client machine(s).

HTH

- Scott

rsbaker0 replied on Tuesday, December 16, 2008

Hmmmm.

I usually think of the validation rules in particular as being part of the BO (e.g. the "server library"), but these definitiely get execute on the "client". I'm not sure how you would separate out your DataPortal_Create,  _Update, etc. methods (nor am I sure what that would really gain you), but it's probably possible.

The definition of "client" and "server" with CSLA can get muddy. With WinForms, the client is obvious, but in an ASP scenario, the client could be IIS rather than the browser itself. With SilverLight, I think the browser is the client.

In general, I'd plan on having the BO layer on both the client and server. What you don't have to deploy on the server is your specific UI library, if you have layered your application that way.

tmg4340 replied on Tuesday, December 16, 2008

I'm making an assumption that in this case, a "server library" might be a DAL-type thing, which is much easier to segregate.  The OP didn't really specify what a "server library" is.

And even in a web situation, "client" and "server" could be fairly well-delineated.  Ultimately, I break it down to local vs. remote DataPortal.  If your DataPortal is remote, then that's your "server", and whatever is talking to your remote DP is the "client".  If your DataPortal is local, then you don't really have a "server" - your client machine functions as both.  Whether the client machine is the user's machine or IIS doesn't really matter at that point.

(And in a web situation, your "client" and "server" could still be the same machine, if you're hosting your DataPortal remotely on the same IIS server as your site.  But they're still different processes, so there's still a relatively clear break as far as deployment is concerned.)

Of course, all bets may be off for SL, and since I have no real experience with that, I can't comment.  It's my understanding that SL is something like Flash, but with minimal .NET interaction on the client.  So in that instance, it's still pretty much like a web app.  But I could be way off-base on that.

- Scott

Copyright (c) Marimer LLC