Does SF implement proper layered separation of concerns (SoC), such as the presentation (PLL), business (BLL), and data layers (DAL)?



Additionally, does the BLL use a Domain Model pattern with a separate Repository pattern for mapping entities to data access operations?



Also, does the PLL use an SoC pattern, such as MVC, MVP, or PM?



And finally, can I use dependency injection?



Thanks.

Michael,



Yes. StrataFrame is a true tier separated framework and can operate in a number of different environments. The documentation goes over this in much more detail, so instead of just rehashing the docs let me give a brief summary.



First, many of the acronyms that you are using (i.e. SoC) are called by other names as well (i.e. n-tier or 3-tier). So many of the things that you are asking may be a difference in nomenclature.



Next, StrataFrame is designed as a 3-tier framework which true physical separate of the DAL (Data Access Layer), BL (Business Layer), and PL or UIL (Presentation Layer or User-Interface Layer).



As for design patterns, we use many different patterns. As for the implementation of a Domain Model Pattern, this would pertain more as to how you write your application than how the framework is written. The Domain Model Pattern is basically a pattern that makes it easy for the flow of business rules and logic to change easily. So this is more driven by the design of your application than the framework. The framework ultimately allows you to work in either model (tightly or loosely coupled business rules). As for the repository pattern, this too is more determined by the design of your application, yet StrataFrame has intrinsic tools to aide in this if you choose to map connections to your data, etc. and decouple this from the application.



If I might inject something here. I too at one point was very academic about my approach to application development reading all of the design-patterns making sure that I understood what each pattern meant and would ultimately mean once implemented into an application. Also, it is really good to have a knowledge of each of these patterns as it will make you a far better developer and produce a better product. But at the end of the day, this is still at the 50,000 foot level versus being down in the trenches where the rubber meets the road. I think it would be more productive if you were to ask direct questions as to what you are trying to accomplish as I think that I would be able to better meet your needs versus talking in theories. I hope that this makes sense.



I appreciate your questions. Thanks.

Hi Trent,



"If I might inject something here...."



Great advice - well said.



Cheers, Peter

Trent, Actually, I've been designing and architecting applications since the mid-90s, and patterns are tried and proven ways of solving common problems (e.g., Repository, Active Record, and others are well used, proven patterns employed in thousands of apps). I literally architect, design, and develop code just about every day. I apply design architectures and patterns that've proven successful/useful over the years, not just serving as theories. There's nothing academic about my approach or my questions. Hence, my mention of those patterns and architectures are relevant to my questions. I will now be giving the purchase of this software less consideration.

Michael.

I guess you missed part of Trent's answer, so I am quoting back here so you can give it another try:

Cheers!

I have a motto in my consulting practice that says "Better to not take a client and be sorry than to take a client and be sorry"

Michael,

It is not my desire to offend or challenge your technical abilities.  That was not my intent nor what my comments implied.  There is a vast difference in asking about a pattern versus an actual implementation.  My point was simply that you ask direct questions as to what you are trying to accomplish versus speaking in ambiguities so that we could better meet your needs.

Good luck to you sir.

Charles,



Did you ever notice that all of us who have been in the business for a while seem to adhere to this motto?



Bill

A Whil Hentzenism, I believe



Hi Bill - welcome to the forum.



I was thinking of you this morning when I posted the tip in the winforms section about changing the parentclass of a control already on a form. I'm finding this subclassing in code stuff to be one of the most interesting and in a lot of ways most useful things I've run across in switching from Fox to .NET.



Just to expand a little on what I alluded to in that post : once you have created a whole bunch of business objects in your app you may decide you want to create your own baseBO subclass of the microfour business object. You just go into your current business objects and change one line of code. Whoooa.



Be sure to check out some of the great tutorial stuff Les Pinter has put up on his website.



Folks, Bill is coming in from a VFP/Maxframe background, so anybody who speaks Maxframe, you might want to give him tips that help the mental shift.

Hi Bill.

I don't speak Maxframe, I used to speak Codemine.

But anyway, welcome to the forum!