Application Architecture..

[matthewking]

Hi all,

I usually develop web applications, but am delving into desktop application development with c#.

Im a little stumped on the archtecture of a .net application, I've gone through the tutorials but they all seem to be a little overdone.

Currently im doing this:

I have a user interface.

I have a BusinessLogic layer which has objects such as 'Customer', 'Order' etc.

Do I need somekind of layer between the businessLogic and the interface itself?

Also does the businessLogic need to call a data layer for db operations? if so do I just put all methods in one big DataLayer.cs or have individual objects for that too?

So my Customer business logic class would call a CustomerDL datalayer class?

Or have I got it all upside down? As you can see im in desperate need of a pointer.

PS: Also I've just finished a SocketLibrary class, where do I communicate with that? the business logic? I've read something about creating a ServiceAgent class?

Thanks,

Matt.

 

[matthewking]

When developing with ASP.NET I have business objects that contain the data access code aswell.

So:

Customer cust = new Customer(CustomerID);, the class itself looks up the info for the customer and populates its own variables.

Shall I go with this approach for a desktop application?

 

[chiph]

The one weakness to having a customer object populate itself is when you want to get a list of customers.

At that point, you'll need to have a separate object to return a collection of customers, and your customer object becomes more of a DTO (data transfer object). It goes against O-O lore to have an object that doesn't really have a lot of methods - that just holds data, but in this case it works well. The only methods you might have are something like a ValidateContents method, and Serialize/Deserialize methods.

Your data access layer then contains the code to enforce business rules (can be in it's own layer if it's complex enough), and to implement the usual CRUD methods (Create, Retrieve, Update, and Delete).

Chip H.


If you want to get the best response to a question, please check out FAQ222-2244 first

 

[palbano]

>> Do I need somekind of layer between the businessLogic
>> and the interface itself?

The MVC Pattern fits well into Windows Forms designs.

>> do I just put all methods in one big DataLayer.cs or
>> have individual objects for that too?

I will say this again, There is no cookbook design in OOD. There are Patterns yes but no complete cookbook designs. The design is based on your problem domain and requirements.

As to the Data Access design. It is helpful to have a single interface to the data source(s). This however does not mean a single object contains the entire data access code for the project. Behind the interface (Structural Pattern: Facade, Adapter, Bridge ) there can be any number of classes that encapsulate specific data/behavior.

>> Also I've just finished a SocketLibrary class, where do I communicate with that?

With socket connections you often have some notion of a session. This session might be an appropriate class to interact with a socket class.

"But, that's just my opinion... I could be wrong."

-pete

 

[matthewking]

Thanks chiph for explaining the inner workings for the model, that cleared up a few things, and Thanks palbano - I think I'll go with the MVC pattern as i've used this in a previous Java project.