By Michael Gonzalez - 3/9/2010
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.
|
By Trent L. Taylor - 3/10/2010
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.
|
By Peter Jones - 3/10/2010
Hi Trent,
"If I might inject something here...."
Great advice - well said.
Cheers, Peter
|
By Michael Gonzalez - 3/12/2010
Trent L. Taylor (03/10/2010)
Michael,
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.
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.
|
By Ivan George Borges - 3/12/2010
Michael.I guess you missed part of Trent's answer, so I am quoting back here so you can give it another try: Trent L. Taylor (03/10/2010)
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.
Cheers!
|
By Charles R Hankey - 3/12/2010
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"
|
By Trent L. Taylor - 3/14/2010
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.
|
By Bill Mason - 3/15/2010
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
Charles R Hankey (03/12/2010)
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"
|
By Charles R Hankey - 3/15/2010
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.
|
By Ivan George Borges - 3/15/2010
Hi Bill.I don't speak Maxframe, I used to speak Codemine. But anyway, welcome to the forum!
|
By Bill Mason - 3/15/2010
Charles,
Drew had a terrific utility in Maxframe that allowed you to assign the parent class of any object on a form or class at any time. I got into the habit of just tossing labels, text boxes, etc on a new form and then changing them all to the project specific versions after they were all there. Made things really quick. (spoiled me also!)
This brings up a question that may be in the docs but I have just started, so bear with me. When building a new project in VFP I would always have "bills-company" class libraries that were subclasses of the Maxframe class libraries. Then I would subclass the "bills-company" classes for each project. I found this gave the the most flexibility but never seemed to impact performance negatively. Does this sound like a good plan for SF?
Bill
Charles R Hankey (03/15/2010)
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.
|
By Bill Mason - 3/15/2010
Hi Ivan,
Thanks! Never used Codemine but I did a couple projects with the original version (from the book) of CodeBook! The client (back in Pittsburgh) is still using the application!
Bill
Ivan George Borges (03/15/2010)
Hi Bill. I don't speak Maxframe, I used to speak Codemine. But anyway, welcome to the forum!
|
By Charles R Hankey - 3/15/2010
Sounds like Maxframe used prg classes. Cool. The .NET version should make a lot of sense then.
Yeah, in VFE we had a layer that was subclassed from the VFE framework that we could customize and count on it not breaking if F1 put out a new release, then we would subclass from that for the app.
A little different here, partly because it is easy to go back and retrofit. If you have developed stuff that actually extends the framework, by all means use it from the get-go in the project, but otherwise just use the SF classes, knowing when you have subclassed them for some reason you can implement the subclasses pretty painlessly.
I think developing a base businessobject - even if at first it has nothing fancy - is fine as that is probably the first place you'll be putting in generic goodies. I also have a seperate project, which for development purposes I keep in the same solution - for subclassed UI controls that I use in all my apps. And in your base assembly/project (see below) you will start building a library of routines you may use throughout the app ( and perhaps later will want to abstract to an assembly you reference in all your apps)
I think a big thing at the beginning is looking closely at the Strataframe sample. Unlike the getting started tutorial, it is more "real world" in showing how a number of projects/assemblies will make up a finished app. That is probably the first big mental paradigm shift to get through in moving to SF/.NET. Figuring out how to reference the other projects within the app is a little strange at first, and then you have to get used to needing to rebuild sometimes before seeing changes in one assembly reflected in another.
You will very much like the convenience SF builds into creating parent/child stuff etc. Les has a good turtorial on that on his website. First gotcha to be aware of is setting the relationship between the parent/child BOs in the solution explorer before going to the child instance dropped on the form to set the parent business object. The trick is to double-click the child in the solution explorer first, then go to property sheet to see the parent relationship property. That is one example of where you may have to build your BO project before you will see the parent in the dropdown when picking the parent BO in the instance.
Some of this stuff looks less complicated when you have everything in one big project, but you'll find that the benefits of have a main project, Base, BusinessObjects, UI, Reporting and maybe some others is worth the trouble.
I'm sure others here will chime in with some good tips for getting off on the right foot.
|
|