Windows app, seperating programming and GUI layer.

Steve Jackson

Hello;

I am trying to write a Windows application in C#. That's easy enough to start up, I know. I am interested, though, in seperating my program layer and my GUI layer - good programming practice.

Instincts tell me to start up a console application, create a form, instanciate it from the console application and show it. Two undesirable things happen when I do that.

1. The console opens

2. The program doesn't persist - it closes as soon as the code is done.

Is there a way to have an entry point class that acts like a form in that it just waits around for events to occur, but isn't a form in itself. I suppose that I could just create a windows app and do a 'this.hide', but that doesn't seem so elegant.

Perhaps I am thinking about this the wrong way. Any ideas

Thanks,

SteveJ

ahmedilyas

Why would you want to create a WinForms app with a Console app That makes no sense. Is there a reason you want this to happen

Why not just create a standard WinForms project Then add your business logic and DAL (Data Access Layer) projects to the main solution which includes the standard Winforms project.

Really, this is the way it should be done, Don't entirely see why have a console and a winforms app together in one solution (not doubting it but just curious to know why)

Steve Jackson

Thanks for the reply.

It's not my desire to create a Winforms app with a Console app, really. I just was thinking outloud as a possible solution.

My problem with simply creating a Winforms app as you suggest is that the first form becomes the trunk, so to speak, and the Logic, external classes, other forms, etc. become the branches. At least that is how I understand it. Am I incorrect

What I want is the program logic to become the trunk from which forms, classes, etc. are instanciated (branches).

What I want to do is something like below, where I use the Entry Class to handle the programs main logic, mainly deciding with classes to instanciate and which forms to show. If I run the code below it will, of course exit after 'mainForm.show()'. I don't want it to close, or be a console app, I would wrather it just hang around and accept events from the different forms and classes that it instanciates.

class EntryClass

{

MainForm mainForm = new MainForm();

AnotherForm anotherForm = new AnotherForm();

SomeClass1 someClass1 = new SomeClass1();

SomeClass2 someClass2 = new SomeClass2();

// Define delegates for events

public static void main()

{

EntryClass entryClass = new EntryClass;

entryClass.start();

}

private void start()

{

mainForm.show();

someClass1.doSomething();

}

private void SomeClass1_didSomething(o as Object, e as EventArguments)

{

// Code here

}

}

Perhaps I am simply not thinking about it the right way, or properly understanding your reply. Are you suggesting something other than replacing "mainForm.show()" with "application.run(new MainForm)" and instanciating by logical layer from MainForm

Anyway, I hope that I'm not making myself look like an idiot.

SteveJ

ahmedilyas

I see what you mean. I think your going way over the top to be honest, as most applications just use a Windows Project (if it is a winforms app). I see what you mean but 99.5% of the time, all winforms applications are just started with the Windows application on its own, which it kicks itself off.

I guess you could do this in your static void main method of your console app:

Application.Run(new Form1());

which will keep the app running until the Windows application, or your console app, is closed

The Program Logic, as you define it, becomes your business logic layer - an assembly. This is what you want.

WinForms (GUI) - UI controls etc.... and calls to BLL for logic, like getting data from SQL

Business Logical Layer (BLL) - All your logic, such as determinating if it requires to fetch data from SQL or whatever

Data Access Layer (DAL) - Does just that, fetches data from multiple resources, such as SQL, files, webservices etc....

Winforms calls BLL, BLL calls DAL should it require it, DAL can also call the BLL should it require it but the GUI layer should never call directly, generally speaking, the DAL layer.

Steve Jackson

Thanks again for the reply;

I'm certainly not opposed to the idea that I'm going over the top. It seems, though, from an object oriented perspective it would be a good idea to make the GUI layers more loosly coupled from the business layer. What if I wan't to completely change the GUI later on I don't really want that to effect my business layer. What if I wan't to instanciate and show a different Main GUI based on the user or computer type.

Philosophy aside, considering the solution that you suggest of "application.run(new Form1)", that is pretty much what studio auto generates when starting a windows application Doing this seems to completely leave the entry class (program logic / business layer), and gives exclusive control to Form1 - which returns me to my original question : ).

Thanks,

ahmedilyas

Yes thats right.

Urgh - your such a complicated user (just kidding!)

Your Business Layer won't be effected, well generally all projects require maintainence any way but your BLL has all the methods it ever needs, and more. The GUI layer should be closely tightened I believe with the BLL as that is really where the requirements come from (The first half of it) - what the user needs access to via UI and what the UI Controls needs access to - the BLL will have these methods to support those requests.

If you want to chance your GUI later on, thats fine. Keep the methods in the BLL and add more methods if required or modify existing ones (tweak them) - no application is perfect.

Take for instance SQL Server. The BLL has always changed as well as the UI but they are both tightly coupled together with still support for the older GUI's, since they really generated the requirements for the methods for the application itself.

Complicated, I know.

KISS - Keep It Simple, Stupid (thats the rule). Interesting discussion though :-)

Steve Jackson

OK, I will concede. If I ever develope my own programming language, though, I will allow it to sit around without a GUI and wait for events to happen. I think that I'll call my new language, 'Steve'

Thanks,

ahmedilyas

no worries my friend, hope we learned something. Do keep us posted though of your thoughts and ramblings :-)

J. Ambrose Little

Steve,

Let me add a slightly different perspective and hopefully some clarification.

1. You should, in most cases, create a Class Library project and use that to contain your domain model (sometimes called BLL). This is where your domain objects, their behaviors, and usually your business logic will reside. There are some interesting possibilities in using the Windows Workflow rules engine in your domain model that allow you to store your business rules outside of imperative code, so you can share rules across applications or, at a minimum, make it easier to change rules (even at runtime). But I digress, a good starting point for any application is a domain model in a class library.

2. Depending on your needs, you may want to isolate your data access layer by using something like the provider model or dependency injection pattern (you can search on these terms to learn more). But often, LOB apps don't need to have a strict isolation of data access from the domain model, so you can put that code into your domain model library--just at least consider isolating it enough so that refactoring it or changing the data layer wouldn't be cataclysmic.

3. You can create a UI/presentation layer project in the tech of your choice. It sounds like WinForms is what works for you, but you could do it in WPF or ASP.NET or Steve's Presentation Framework. It is totally fine for this to be a Windows Forms application project (in VS), and in fact, that's probably the best way to go to avoid having to manually set it up to run as has been discussed here.

Now, if you want another layer of separation between the UI elements themselves (views) and the domain model, you can add a controller or presenter layer (hence the model-view-controller and model-view-presenter patterns). It sounds like maybe this is what you are imagining. It lets you define contracts between your model and views that make developing a more loosely coupled UI possible. If you are interested in this, I suggest you check out the Composite UI Application Block (CAB) as it does the grunt work of the framework for you. And in the future, keep an eye on Acropolis. Third parties like Infragistics offer ways to integrate their UI stuff into these kinds of frameworks.

Also, if you want a full, aided/rapid application dev tool that builds on these concepts, check out DevForce IdeaBlade. It's a pretty impressive tool, IMO, particularly if you have a pre-existing data source. They, too, offer a pluggable UI framework for integrating third parties.

Anyways, the key things are that you're right in not wanting to start from a WinForms app. When designing an application, you're best starting with the domain, modeling the objects in the domain, their relationships and behaviors, and creating that in code (class library) so that you can use that with any UI. Also, if you take this approach, you can later then relatively easily expose your application's services to others in an SOA environment--this is not really doable without major refactoring if you don't separate the domain logic from the UI.

Steve Jackson

Wow, thanks for taking the time to make that post, it was great! I should have mentioned that I still swim mostly on the shallow end of the pool with respect to software development. I think, though, that I was able to gleen something out of it. Let me try to repeat what I think you said, back to you, so as to ensure that I understood.

Firstly, I think that I've done a fairly good job on this project of establishing entities, relationships, business rules, etc before beginning coding - which Is why it made sense for me to seperate the UI and business layers. That is how the design was modeled.

I think that I have been careful about seperating the data layer, ensuring the use of interfaces as not to trap the business layers into using a specific type of data I/O model.

It sounds as if you agree that is is a good idea to use the same techniques for the UI layer, that is to establish interfaces that must be implemented by the UI to allow its use by the business layer. In this way - I could completely change the UI in the future without adversly affecting the operation of the business layer.

After that, I become a little unclear as to what exactly you are saying. You suggest a couple tools such as CAB and IdeaBlade, but make references to Winforms being a good way to go as well. I'm unsure if you are suggesting that I can achieve the seperation that I desire using Winforms. If you are suggesting that, then I would follow up by asking how As I suggested in previous posts, I am unsure how to get a non-windows startup class to stay open - without perhaps initiating an endless loop or something.

I'l try to work through the reading of the other links that you posted. I have started already, but I have a low level of confidence that I'm not going to be over my head in short order.

Thanks,

SteveJ

J. Ambrose Little

I wouldn't say that the business layer should use the UI interfaces. There's actually another "layer," if you will, that the MV* patterns introduce that deal with the interaction between the views themselves and the business layer (domain model). Your domain model should not typically have any knowledge of your UI layer. The UI uses the domain model, not the other way around.

Both CAB and IdeaBlade are WinForms-based tools, so it's not an either-or proposition. I suggested CAB because it implements the MVC pattern for you, providing a reasonably easy-to-use MVC framework out of the box. I suggested IdeaBlade's DevForce because it actually does a whole slew of stuff for you--you can build an entire WinForms-based application using their tools. Both of these tools are added value on top of .NET and WinForms.

To keep things simple, you can just ignore the bits about MV* and CAB. If you're encapsulating your domain knowledge (objects, behaviors, rules, etc.) in a separate layer from the UI, that's the most important thing. Then just create a WinForms app and reference the domain model project (or assembly) and have your UI manipulate your domain model directly. The main benefits of this approach are that you encapsulate your domain knowledge in a reusable library that can be used by multiple UIs (be they WinForms, ASP.NET, Web Services, or whateva). More often than not, it's the UI that folks want to update as technologies change--the domain knowledge doesn't change so much, so keeping those two separate is key.

Later, if you feel comfortable with it, you can look into using the MV* patterns and CAB. If you feel overwhelmed, just take one step at a time. That's partly why I suggested DevForce, because it wraps a lot of this knowledge up into a GUI tool for you, so you don't have to learn it all if you don't need or want to. If you have the time and desire, by all means, delve into all of this. Just realize there's a lot to learn, so don't get frustrated if you feel out of your depth as you're learning it--everybody does...

Stanly Johnson

Hi guys,

Wont it be a better choice to

1) Create the business layer as a remote object which can be hosted in the windows service

2) From the windows form client communicate with the remote object

gverma

Hi

I would suggest you to look into the Message broker pattern that way your biz logic and UI can be decoupled and ou can change your UI without any trouble.

Hope this helps

Gaurav

Steve Jackson

Stanly, Gaurav;

Though this is getting a little over my head, am I hearing you suggest basically the creation of two different projects (maybe within the same solution) and using some standard methodolgy of transmitting information between the two

If this Is what I hear you saying, I am still back to my original problem - the one of getting a non-GUI application to stay alive. If the business layer doesn't have a GUI, how do I keep it from closing as it is setting around and waiting for events to occur

Did I understand you, Stanly, to suggest that I create the business layer as a windows service That peeks my interests, but it sounds like it might be difficult to debug and maintain.

This is a great topic - I really appreciate everyone's response.

gverma

Hi

This is a fair question. If this was java world you could have used a session bean.

The possible options you might have are

1) Creating a web service

2) Having a windows service which keeps pooling a Database or MSMQ for requests

3) Creatinga custom App domain which listens to a database, MSMQ or even sockets (sockets - I will not recomend this)

Hope this helps.

Gaurav