Full Separation of Concerns

[stanlyn]

Hi,

After viewing several .Net, AspMVC, and RubyOnRails training videos the instructors are all talking about a full separation of concerns where there are essentially 3 areas (presentation, business logic and data) where each are totally separate from each other which makes it easy to change either part to a different technology. Such as switching front ends or back ends without changing anything else.

So, now I'm thinking about how I would achieve this in VFP where VFP is known for its tightly coupling these data, business logic and presentation layer stuff. So, how can I totally achieve total separation of the 3 layers in VFP?

I know that I can:
1) talk to the data layer via odbc,
2) let the middle layer (business logic) query the data layer and build cursors and apply the business rules to them,
3) then let the front end layer further massage the data and present the data to the user.

I've done the 123 stuff above, but never with full separation as there was always something bleeding from one layer to another. I've seen this stuff taught in VFP in the past, but I've never understood how to make all 3 layers independent of each other. Any thoughts concerning this is highly accepted, and thanks...

Stanley

 

[JRB-Bldr]

While others here may certainly have their own ideas to share, you might also try doing a Google search for: vfp "3-tier"

Where you will find the topic discussed by others.

Good Luck,
JRB-Bldr

 

[Olaf Doschke]

You've got a good idea about what each layer would do and how it would work.

Some would say the layers would only be really seperate, if you could compile them seperate and replace them one by one. On a large scale you do have this in the form of database servers running in clusters in a SAN and an Application server, which mostly is an idea you find in Java applications, WebSphere perhaps being the most known Application server. And then you have the UI layer, which in Windows now has 3 main platforms: Winforms, WPF and HTML5. Silverlight is the small brother of WPF, so I don't count it as really seperate.

You can compile DLLs for data access, business logic and an EXE for presentation via Winforms, but then you cause costs for traversing the layers, eg you query data via odbc into cursors, but as that happens in a seperate DLL the business layer would need to retrieve something else, like XML, convert it internally and finally the same thing would be repeated to the frontend layer. You lose a lot of the good stuff.

One main thing I'd call good stuff is the way foxpro controls bind to data and write back. If you work the 2 layer way of dbfs and forms with dataenvironment, you can almost do with no code at all, as you can bind data at designtime and you're done. Dataenvironment opens tables, controls display records and write back to them.

If you aim for browser, you lose that advantage anyway, then it's easier to cope with that cut, and live with converting your cursors to HTML toward the frontend or to XML or JSON, if you involve Ajax techniques, like jQuery to get data from the web server, and handle the UI. For example you could use ActiveVFP for that matter, as is discussed in the also very current thread thread184-1703113

There is a compromise to keep everything in one EXE and still have your class design in a way to be able to put things together in the spirit of seperated layers. Mainly because the only way VFP makes sense as one of the three components at all is, if also another component is VFP. Either you use a VFP frontend and VFP for the business layer and keep data in a server like MSSQL or MySQL Or you use a VFP business layer to easily work on DBFs with VFPs ways and have a HTML frontend. But I don't see where you ever would use VFP just for the forms, the advantage of the data binding is lost, if you need to take something from elsewhere and convert it to cursors for the foxpro UI. Also I can't imagine writing only the buisness layer in VFP. Well, perhaps you could use ActiveVFP to work with MSSQL and feed a HTML frontend, but then only to recycle your code, not if you start from scratch and want to do a HTML frontend to a SQL Server database. Then there are many other more convenient ways. The only single VFP layer case I can imagine is only having DBFs, but then you'd probably seek to migrate data elsewhere.

It's quite common to have an SQL Server Backend to a VFP application frontend with Winfors UI and VFP business logic. And besides ActiveVFP there also are other ways to use VFP as the web server side of a web application. Other well known components are West Wind Web connection and AFP and some more.

It's quite easy to seperate the UI, you know you can program in a way you could also do anything from a command line or PRGs. Or in terms of the 3-tier model, you could call into the methods of your business logic and get all you need for any frontend to work on. If you think of the dataenvironment of forms to be very tightly coulöing the 3rd to the first layer, we can also use tables anywhere else in pure nonvisual classes and add them to forms at design time or runtime, you don't depend on the dataenvironment of SCX forms. We also have a seperate dataenvironment class now, to decouple that.

The other lay to seperate is the data access, and for that matter you can use local views and quite easily replace them with remote views, once you want to change from DBFs to any other database. Both view types force you to think in SQL and not simply query all data of a table. The next level of seperation is SQL Passthrough (SQLExec mainly), that gives more possibilities than just SQL-Insert/Update/Delete queries, and the final level of seperation has come with the cursoradapters.

Before we had that there already were a lot of frameworks with data access objects based on views or sql passthrough, which were and are more advanced than what the cursoradapters offer, but the cursoradapter has some very low level things you could not do with the older vfp components, for example it has several Before/After Events you can't implement with SQL Passthrough. And you can incorporate some of the stuff found in data access objects of frameworks and add that to the cursoradapter class.

If you have more specific questions on how you can seperate these layers in foxpro, ask them. At this I won't go into details, I wrote enough for a first answer, I'll just add that such implentations of the 3 tier model exist and can also be bought, like VFX, ProMatrix, Mere Mortals and others.

Bye, Olaf.

 

[Mike Lewis]

Stanley,

This is an interesting question. I suspect this thread is going to run for a long time.

I don't recall ever hearing the term "full separation of concerns", although it's obvious what it means. VFP folk tend to talk about multi-tier development, or sometimes multi-layer or n-tier.

By the way, you said "I've never understood how to make all 3 layers independent of each other". In general, the layers are not independent of each other. That's not the goal. Layers will have various mutual dependencies. For example, the business logic will depend on the data layer to obtain the data it needs, and it will require the services of the user interface to diplay error messages.

The goal is to limit those dependencies to a well-defined set of interfaces. So the busines logic knows that the user interface can display an error message, but it has no idea - nor does it care - what shape or form the message should take or what mechanism is used to convey it to the user.

Also, you described three layers. While typical data-based applications are often built on three layers, there's nothing magic about that number. The concepts apply equally to architectures with more than three (or sometimes with only two) layers.

I'll look forward to reading what other forum members think.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips, training, consultancy

 

[TamarGranor]

You might find this paper I wrote helpful:

http://tomorrowssolutionsllc.com/Materials/Granor_Business_Objects.pdf

Tamar

 

[claudefox]

Since you mentioned .Net, AspMVC, and RubyOnRails, I'm assuming you have an interest in web and foxpro so I'll point you to ActiveVFP or FoxTrails which do the same thing.
ActiveVFP (

http://activevfp.codeplex.com)

allows the Controller (C part in MVC) to be a Class in a simple .prg while the View can be anything - HTML, JSON, etc. The Model of course is the dbf/dbc or any other backend. AVFP MVC implementation is similar to ASP.NET's MVC.
FoxTrails (

http://www.foxtrails.org/)

is based on CodeBook (which is a separation of concerns in desktop foxpro going way back) and RoR!

 

[stanlyn]

Hi Tamor,

I've spent a lot of time reviewing your article, and frankly its overly complicated due to the nature of the apps that you were building. I still have no idea on how to create a business object that does basic crud operations to the backend from the frontend along with the wiring it all up. Also, how are the frontend's control's controlsources set and how will they persist. Do I always need to be thinking stateless now?

Any step-by-step white papers on building and implementing a simple parent child app using business objects. You did mention that in order to have true separation we must use non-visual classes, as visual classes specifically is part of the presentation layer.

Thanks, Stanley

 

[stanlyn]

Hi claudefox,

> I'm assuming you have an interest in web and foxpro
No, not really. Through watching .Net, AspMVC, and RubyOnRails training videos, and for years have been hearing the buzz about this 3-tier stuff, I's started the exploration on how VFP would implement it. Earlier when we were only building desktop apps this stuff really did'nt make much difference, but now with web, cloud and mobile development being part of the mix, its clear to see its importance.

So would ActiveVFP be a good resource on learning the MVC stuff from a VFP perspective? And I'm assuming that MVC is equal to 3-tier??

Thanks, Stanley