Houssam,

Great feedback...I've responded to your questions below.

>- 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.

We plan to implement a two-part business object similar to what we did in MM VFP. The first part can be stateful and is accessed from tier 1. The second is stateless and can reside on a physically separate tier (and can be hosted in COM+), which sounds similar to what you're requesting. This design gives you the best of both worlds and allows you to place business logic in either component.

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

You can actually put them in either place...or for that matter, within stored procedures. Although the MM .NET Developer's Guide shows the simpler approcah of placing SELECT statements in the business object itself, the guide also discusses creating custom data access classes. You can choose to place your SELECT statements within these custom data access classes.

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

That's part of the documentation I'm adding now. MM .NET does handle multi-user concurrency errors.

>- 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.

These are some of the things we're looking at for adding some RAD tools to the framework.

>- 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).

We actually are using the MVC pattern in Windows and Web Forms for data binding in that our user interface controls respond to events raised by the business object. I haven't taken a close look at the MS pattern you mentioned, but I'll check it out.

>- 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.

That is an option we had considered, but in this go-round we have implemented it at the UI level because we found our end users much preferred setting up security this way. I think you'll get a better idea of what I'm talking about when I release the updated docs that describe security.

>- 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.

What we've done instead is implemented interfaces in our controls, which can also be implemented in third-party prodcut controls. The code that does all the work is located in strategy classes which can be called from any UI control.

Regards,