Hi,

Congratulations on your wonderful design! But like any design, it's not perfect.

I was involved in the design of a .net framework for my company, until I ran into your product, then I decided to shift to it. I am currently studying ways to adapt your framework to ours without changing the source code as much as possible. While doing this, I ran into some questions that I need to have some answers on:

- How well your framework fit into multi-tiered architecture? What I mean is, you encourage deploying business logic with the presentation tier, while theoretically, it should reside in a separate application domain, like in a server as web services. In reality, your approach makes some sense, especially with Windows forms. Its not practical at all to perform all the work on the server while we could let the client machine do some of it. On the other hand, placing the whole business logic layer introduces some security risks as well as scalability issues.
I suggest that you should have one abstract class (which itself implements a public interface) as the base for business components; from which we could inherit to implement another statefull class for user-interface-specific data access tasks, and another stateless class for the actual business logic. The latter is intended to be placed on a different tier and will probably have its own business façade layer.

- I think SQL-statement properties in the business component are misplaced. Shouldn’t these be placed on the data access class instead?

- You haven’t mentioned anything about concurrency error handling capabilities, although there are some classes that implement them.

- I think your framework could use a schema designer. First, I can be used to set some business rules at design time. Second, it can be used to generate business and data access classes accordingly, as well as a typed data set class. Third, it will be used to synchronize table structure with the database. Finally, it can be used to implement the appropriate code (SQL/programming) to handle an important but almost always ignored database design pattern: one-to-one relationships.

- It seems a user interface workflow manager and the MVC design pattern is absent from your framework. I recently had the chance to study one coming from Microsoft (http://www.gotdotnet.com/Community/Workspaces/workspace.aspx?id=0af2b0ef-b049-401a-a2f2-f55a070c1572) which I found very useful. Do you think there are any considerations we that should take before merging it with your framework? I found one thing in this regard, which is we should either re-implement your base forms or theirs to have one common base form. I think your design could get away with this problem, and probably come up with even a better design, by implementing your specific form logic as a separate component, which will hook to any control, not just forms (I thought of this because we may be using user controls with business components instead of entire forms).

- It seems that you’ve based your entire security logic on the user interface. While I think it should be placed in the business components instead. A solution could be found in the schema designer I’d mentioned earlier. This schema builder should also be available to the end user at runtime. Besides allowing him to extend the schema or add additional business rules, it will also be used to set module-level, table-level, field-level and even record level security. Client-side business component should be able to determine user rights and enforce them. Controls and command buttons should also be able to render themselves accordingly.

- Finally, we have a set of user interface components different than the ones that come with .net. To use them, we will have to sacrifice the code that comes build into your components. Wouldn’t it be better if you had implemented that code in a property provider class? I think this way we could easily write our own property handling code for each type of control.

Besides those long comments, your framework is promising.