Are we talking about Winforms? If so, forms inside a DLL will work best in this scenario for your teammates. Your MDI main app is mostly static at this point. Most of the dynamics will be done by your DLL "authors".
These DLLs must expose some public methods as well as constructors so that they can be called from your MDI main app. They may also employ the use of delegates in the event they may wish to update the main app's screen (e.g. Listbox, StatusBar, etc.). I have applied this approach before in an existing application which was written in VB.NET 2003. I interfaced my C# DLLs into it and got it to work. Btw, it would be best if you employ the MVC pattern at this point. It will help you maintain your code: De-coupling your business logic and the UI. Cheers! Benj On Aug 9, 10:25 pm, TomServo <[email protected]> wrote: > Hi everyone, > I am working on a C# 3.5 project, and MDI basically. This MDI will > host three major controls, one navigation, a treelist, and a grid. > Those will all reside in the MDI form. Recently other groups in my > organization have shown interest in the data that I am providing > through this app, and they want to be able to have this data available > in their own respective apps. To be more precise, they want to be able > to host the treelist and maybe the navigation control in their own > apps. Now of course they like the control but the mainly want to see > it live, which means I have to provide it with state. The > architecture of my project is basically a UI project ( which has the > MDI ) , a controls project, and a DAL project ( gets data, caches, etc > etc ) > I have the following issues which I wish to share with you and see > your comments on them : > a : If I am to provide the controls, that means they maintain state, > which also means that they have to have some > data access functionality, what I am thinking is embedding the > Major DAL functionality in the controls project. > recommendations with or against this? > > b : For this embedding to happen I have to provide a way for other > apps to initialize my controls. The control reacts > and fetches data based on the login_ID.I am thinking of exposing > some properties on the control ( such as login > id ) , but keep all major methods or event encapuslated. and I > guess I am asking what would you gentlemen > recommend? for example, should I enable constructor > initilization? or maybe an onload event? > c : At some point in the future, a user in a client application might > want to right click on my embedded control, and > through that initiate some action on his app. I am thinking of > raising an event, with some parameters. Any > recommendations with or against this? are their other ways of > achieving this? > > I guess I am sharing my vision of how can this be achieved hoping that > you guys might be able to critique them. > I can think of the folowing information to help you in understand the > environment : > 1 : The entire org is running on a WAN, deployment is handled by > seperate teams and dll deployment should not > be an issue. > 2 : This will be deployed globally, the universal fact is that each > user has to have a login ID. > 3 : controls should have some caching in them, which is why DAL will > move with the control. > > thank you guys and hope you hear some interesting feedback soon.
