Henry is definitely on the right track. Think of forms as layouts. Which in turn have panels. You then create a user control for the "subform" and load it into the right panel of the main form. This works extremely well and now you can decouple your views and reuse them in different layouts and containers. I hope that this helps you.

The CSLA Framework from Rocky has been around a long time. Rocky has updated this for many years and a lot of companies use it. My understanding is that it is very good. There are other frameworks as well that might be used such as Smart Client Software Factory, Web Client Software Factory, ASP.NET MVC and the brand new PRISM for WPF and Silverlight. Personally, I have been sticking to the Microsoft Patterns and Factories. Then my model, my presenter, my view and/or controllers can be reused between them. All of these have things in common. The model, the view and the presenter or the controller. I personally like MVP since it truly encapsulates the actions, rules, transitions and translators into a reusable framework that can be used and easily adjusted as requirements change. If there is one thing for certain in this world - requirements change as the users or management see things evolve. The ability to know where to go to make these changes without Spagetti Coding is crucial to success. It appears that you have a good handle on the tiers here and their requirements. So here is my take. This is only my take and not a definitive answer. So if it is usable then hey use it, if not applicable to your case, file it away for later. The supervising controller is used to centralize the methods between views. All events that can be shared should be fired up to this controller and the controller in turns then fires commands back to interested views. It is very useful for keeping the views of data synchronized on the same class. So supervising controllers listen to events and fire commands to controllers which in turn fire the view events. Now you have a loosely coupled set of views that can be reused between modules without having any dependencies to any one parent container. The supervising controller handles the work and the actions, the view is merely a container with very few methods and the controller for the view has specific methods and interfaces to make the view do things. The controllers talk to the model and obtain most of the data then rearrange it as necessary using LinQ to Objects or if you are using generic list then use the predicates to handle the where clause etc. All views in turn should handle the same interface so the controllers fire things in a coordinated fashion. It keeps you from getting confused as to what to do. Over time you will see exactly how to do this and it will become automatic. Some of the model patterns that I use are the abstract factory pattern for the repository obj

Hi, First I implemented a bindinglistview which inherits from the BindingList and implements all necessary interfaces such as IEditableObject, etc. From there I used this in a custom collection that takes care of the Adding New logic. All of this came from the Data Binding with C#2 book but I cannot remember the author at the moment. Great indepth discussion in a single chapter on how to bind with objects. It also works well with the Interface during design time. Happy Coding

Most major version control systems such as SourceSafe, CVS and PVS allow for version control of the underlying script. In fact, SQL Server 2005 is tightly integrated on a project basis with SourceSafe out of the box. So I do not understand this as a reason, but hey to each his own.

From the managers point of view this may seem perfectly logical. However, assuming that you do not put business logic in your stored procedures it is rather trivial to adjust the stored procs for each RDBMS and in fact it is quicker than changing code in multiple locations. The real question here is not so much speed (although important) but maintenance costs and security. If a table changes then it should be easy to identify all stored procedures that access the table to update. This is far quicker than sorting though the various lines of code, classes and other mechanisms to find the offending sql string. From a security point of view (ala SQL Injection attacks) having stored procedures is better protection than dynamic SQL which the coder forgot to eliminate a rem character or character. Finally, I have worked with all major RDBMS backends and there are some differences in the SQL. The SQL however is different regardless of whether you call it in a dynamic query or stored proc. In fact it is easier to deploy to multiple RDBMS backends when you have scripts for each stored proc that are optimized for each backend language. Again, maintenance is cheaper. Let's face it PL/SQL, MySQL, or DB2 will cast a string to a date differently than T-SQL. These are easier to find when you are compiling the database scripts (yes they all throw errors on compile if they are wrong). Management should respond to the issues of maintaining separate code bases for separate back end databases. This really only works if you separate out the business logic into a separate area (usually class library) and keep the stored procs for CRUD work. My thoughts only and I will be interested to hear someone else speak.:rolleyes: