Creating A Loosely-Coupled / Scalable software architecture

Question

I\'ve been researching this for weeks. I\'m currently designing a loosely-coupled architecture design using n-tier (3-layered) method and factory design ap

Answer 1

My first comment would be that your names need to be much more descriptive. It's not obvious at all what your program actually does by looking at the solution outline. If you give your client classes and your workspace meaningful names it'll be a step in the right direction.

Answer 2

The only thing I see, and I mist just be missing this in looking at your post, but I don't see a DAL interface definition or abstraction layer that seperates it from your BL in the way your BL is abstracted from your presentation.

This is important because it gives you the flexibility in the future to create a new business layer using the same data without having to rewrite the DAL, or replacing your database with flat CSV files/mocks in unit testing/a 3rd party maintained soap web service response, or whatever else might be a better data storage mechanism in the future.

Answer 3

this question came out too broad, there is not a single best for all approach.

Personally basing extension points in adding classes and inheritance without a real case that strongly benefits from it is something I've seen ending in great complexity all around.

Its very hard to tell with the amount of info provided, but consider the alternative of using a more configuration based approach / don't mean config files, just configurations that are passed into the system.

You can have a set of basic rules, and a default configuration that applies a set of those rules to a client. If you are doing it in code, when adding a client's config you may just say .AddClient("ClientA"), and it'll use only default rules.

Alternatively you can specify the rules that apply to the client's processes when adding the client, which can involve setting different rules or even different configuration values for those.

ClientA can have a need that's not included in the basic rules, then a custom/code business rule can be applied to the client process.

I wouldn't try to make the jump all the way to such a generic framework. Instead I'd keep the above focused on the specific processes and exposing extension points for those. As you work in the solution, common patterns should emerge and then if appropriate (a real benefit is seen) you can refactor it to something more general.

Answer 4

You've got a basic violation of Separation of Concerns/Single Responsibility Principle: Your business objects know about their storage.

The Data Layer of the 3-tier architecture should be responsible for CRUD operations, and should be queried for instances of the objects consumers need. Something like this:

Presentation Layer ------- Data Layer
                              ||
                              ||
                       Business Layer

This allows the business layer to focus on implementing, and keeps the persistence concerns out of it. If the Presentation layer needs a new business object (for creation), it asks the data layer for it.