n-tier application (remoting)

hi!

I want to have the business-layer not only to serve as datasource for the presentation-layer. What i want to do is that the presentation-layer calls methods of the business-layer which also contains form elements.

The presentation-layer should only contains a mdi-form, menu, statusbar etc. The business-layer should contain all forms and all coding which is necessary for the form. Is something like that possible with remoting?

I've read many articles about .net remoting but all i could find is that the business-layer sends data (binary or xml) to the presentation-layer who contains the necessary routines to display the data.

thanks
robert

In n-Tier applications it is generally the idea that the presentation and business layers should be seperate. This follows the idea of the structure in that part of its purpose is so that the presentation layer can be changed easily (web to windows, windows to web, etc...) without having to change the actual processes that do the work (the business layer). That is probably why you haven't read much about it.

Forms present data and as such are inheritly part of the presentation layer regardless of whether or not they are in the same assembly as the main application or not.

Now having said that, you CAN do that with or without remoting, the real question is SHOULD you do it. Remoting is simply a mechanism of communicating between different application domains. Although serializing a form would be a bit tricky and more of a pain than its worth.

At the moment all my 'forms' are custom controls which are embedded in a container inside the mdi-form.

The idea of implementing those custom controls in the business layer is that i also can embed them in a browser window if necessary and that it isn't necessary to deploy the presentation layer to all clients if a custom control has to be changed.

Is it possible that the client gets a reference to a custom control by MarshalingByRefObject which is hosted by the local proxy? In that case the custom control could be used by the client like a 'local' object...

Are these .NET custom controls? Are you planing on using ASP.NET? If so you should know that ASP.NET runs entirely on the server side. Also not all winform controls can be used in ASP.NET, in fact I think most can't. Are you sure your custom control will work in ASP.NET?

Also, this is just a language thing, the business layer does not refer to any outside dll it refers to the classes or means by which you validate or apply any business rules. You can have external dlls that are not part of a business layer. It seems like you want the forms to be in a seperate dll for deployment reasons, but to say they are part of the business layer is not really the samething.

yes... all custom controls are implemented with .NET. I've never tested those controls with ASP.NET but i thought that this would be possible without any problems :blush: But that's not so important for me because right now i've no plans to use ASP.NET

It's not easy for me to understand how this could work... the business layer should not refer to any outside dll. All entity definitions (typed datasets) and the methods to operate (read, update etc) on those datasets are implemented in a dll. Those dll's have to be used on the one hand by the business layer (which only contains rules and validation) and on the other hand by the dll which contains the forms because there the methods 'datasetToForm' and 'FormToDataset' are implemented.

This is how i want to split my 'thick client':

presentation layer:
- GUI

business layer:
- business rules / validation
- business entity definitions and operations
- error handling
- cryptography handling
- DB and BLOB handling
- reporter handling
etc.

data layer:
- SQL-Server

Nevertheless this is not a 'clean' implementation of a n-Tier application i will try to do it that way (if possible) because it fits my needs.

Thank you Edneeis for your help

how are you passing data between the business layer and the gui?

I've read a lot of theory about building apps this way but have so far never had to do anything big enough that would have benefited enough from the extra time of thinking and planning it.

Well that's the important thing whithin this implementation. I do not pass data between the business and the presentation layer! Only GUI-Objects (= user controls) are passed and those objects include all operations on the necessary data.

At the moment my application is also not big enough to have benefit from splitting it but i think it's not only a question of modern software design. The earlier I change the design the easier it would be and the biggest advantage is that the application is more scalable if you use a n-Tier architecture.

I usually mix my Business and Data Layers to provide an object that the Presentation Layer then works with. So the form only sees and uses the Nurse object and the Nurse object handles validation and makes any calls to the database. The only thing the form provides for the data is the connection which I accept as the IDbConnection type so I can switch between the different types of data connections (OLEDB, SQL, ODBC).

That's a little bit different from the way I do. The forms only uses the entity objects (for example business partner, bill etc) and between the entity objects and the database i've implemented a db-helper class which manages the types of data connection.

Right now i'm trying to split some parts of the thick client into DLL's... but i've the first problem. DLL x has to refer to DLL y which refers to DLL z... but DLL z need DLL x! Where do I have to start compiling?

I think I've to redesign some parts of my application in order to separate it.

I also use an architecture similar to Edneeis. The UI simply works with an object supplied by the business tier. The object then communicates with the data tier (uses MS Data App Block) for population, updating, deleting...

I have also been staying away from datasets when possible (except complex searches that only serve to give the user a listing to choose from - then create the object) and instead favor the datareader for it's speed.

Even if you could figure out how to send a form or UI controls through the wire for remoting / web services, I don't think it would be very efficient.

Where do you implement the elements (forms etc) of your UI? Are they within the client or do you have a DLL which is located on the server of the business tier?

All of my UIs are on the client. I have some UIs in dlls that are reusable across applications, but these are also on the client, and included with each application as needed. But all UIs interact with the business objects tier. No UI is allowed to access the database itself - only through calling functionality in an object.

Do you know if it is possible to have all UI elements in DLLs which are located on the server of the business tier? This would be nice because in this case a changed DLL hasn't to be deployed among all clients.

I read an article how to register DLLs for remote use but I've never done something like that. Another aspect you metionned in your last posting is that this way wouldn't be very efficient.

I have breifly looked into Remoting and Web services in the past and you still need to reference the dll that you want to have on a server in your application that you want to deploy. This makes sense, so that the client application knows about the types and objects that are in the dll.

So this means that if you think that you can change the dll on the server and all your client apps will be fine - well you are right and wrong at the same time.

If you change the public interface of anything in the dll, then it will affect your client apps. If you had a method like Public Sub New(ByVal x As String) and changed it to Public Sub New( ) then it would break all your client apps that call that function. However, if you change the dll internally (not affecting the public interface), then there is no problem. This would be like adding a new private method that is called by some other method, changing internal validation code, etc.

Also, what I meant by efficient is that when you serialize an object, it has to serialize all objects that it contains, so this would mean all of the controls on the form, any other objects referenced, etc. To me it would seem like a whole lot of stuff to send back and forth.

Well if depoyment is the main issue then you have some other options. The strongest I think, although I haven't actually used much of it, is the ability to load an assembly from a remote location. You could use Assembly.LoadFrom to check for a new version and download it locally and use it. This works over the intra or inter-net. There is also a .NET Updater component that someone has built. Here are some links that should help:

http://windowsforms.net/articles/appupdater.aspx

http://www.code-magazine.com/article...uickid=0307061
http://www.fawcette.com/reports/vslive/021202/vsnet/
http://weblogs.asp.net/jsemeniuk/posts/9122.aspx
http://www.gotdotnet.com/community/w...f-fdf1301902f5

Yes... maybe that's the solution for me! The UI elements are in one (ore more) DLLs on a specific server from which they are loaded. This way it should be possible to deploy the UI elements and to have the business tier scaleable because this part is implemented by using .net remoting.

Yes, I actually use the auto-deploy functionality, so I have a single client application that shows users their applications in a drop down. When the select one, it is auto-deployed to the client machine from a webserver (IIS) and run locally - so they always have the latest version of the application.

I never have to deploy anything manually to the client machines after the first install of the client app. I just put it out on the server and I am done. It works great!!

To make it even sweeter, I have the cleint app using the auto-updater functionality, so that if that ever has to change, I don't have to do another install of it everywhere. I just put the new version on the web server and change a config file to point to the new version. The client app polls the config file every so often, and at startup, to detect and download the new version.

Once I figured all this out, I am a happy man :D

ok... now that I have the necessary information on how to split my application (remoting, auto-updater...) I'll have to do the coding. I've no idea how to start so any examples would be helpfully :)

Thanks to Edneeis and VBCrazyCoder for your help.

I think I'll be back soon (with new problems of course!)