I build an app with following layers:
WEB presentation layer
Business Logic Layer - BLL - called from WEB UI through HTTP web services
WindowsService - Runtime - called from BLL through net.pipe
BLL can also be called from 3rd party for integration into other customer's systems.
Let's say that there is an validation error that happens in the Runtime or even BLL. Where would be better to put translations:
in the exception message - means
that we must send UICulture from WEB
layer to lower layers
BLL and Runtime are returning error
codes or custom Exception derived
types and translation is performed
in WEB UI layer
some other method
What is the best practice for supporting multiple languages in SOA architectures ?
EDIT:
I should probably use the term tiers instead of layers.
WEB UI tier is implemented in ASP.NET web forms and will be deployed on server A under IIS.
BLL and Runtime will be deployed on server B but are separated by process boundaries (BLL runs under ASP.NET worker process because of WCF services and Runtime runs as separated windows service process).
My advice for your issues is general because I do not know the specifics of the .NET platform you are working with.
From your question, I see two distinct problems.
You web presentation layer will be language-dependent. It will require custom CSS, fonts, spacing and even custom content. Do not fool yourself that this will not be needed. This is one of the biggest mistakes people make initially when internationalizing web applications. You will need another style for the language. So, if you are using a template approach you can put most of your language content right in the language-dependent template.
From the description of your problem, it sounds like you will also need to handle localized error messages. There is two approaches two this: you can have a language file where you localize when the error is thrown using a resource file solution. Another approach is to have your error messages use a common identifier and parameters and have another layer catch the message and localize it. I myself prefer the former solution since it is simpler.
Also remember that if you are writing your error messages to a log file, that the error messages are in a language that the developers can read. Likewise for errors displayed to users in the GUI, you will want some way for the users to identify the errors to the developers who do not speak the user's language. This could be done by using numbers - I prefer using short keys like DATABASE_ERROR_BAD_QUERY.
The translation should be handled by the presentation layer as it relates to the view. The more context that can be added to the message the better and the business logic might not be aware of the context nor should it be.
An approach that I've used is as follows:
Business logic throws unique, defined
error codes which can be used as keys
into a resource bundle to get a
translated message.
Presentation layer maintains a text
package containing all the error code
translations separate from the
general presentation layer code.
The presentation layer depends on
both the business logic and the text
package.
3rd party clients of the business logic, like a web service,
can choose to include the text
package as a dependency if they want
the standard error code translations.
Otherwise they can handle the error
codes thrown by the business logic on
their own.
I'm not quite sure what is your definition of the WEB UI. If you use the MVC pattern, the Controller would be place to take care of showing the right language version in the UI, while the text itself would be in the View layer. What I didn't understand is what plays the role of the controller in your architecture. Does BLL mean only including processing logic and no communication between UI and Services? If so, then probably the Web UI layer would contain the localization logic.
I would also say that it depends a lot on the technology you use in the project. ASP.NET for example has a built-in localization model that you can use. I'm not saying it should serve as an example, even on the contrary - ASP.NET breaks separation of concerns. But I think this is an issue, which would have very different solutions in different custom architecture models, as in your case.
Based on how your application is structured, you may need internationalization in two locations:
1) Software itself. Menus, Dialogs, Messages, Labels, Reports, etc.
2) Content. Your application when running in more than one language will likely need to handle content in more than one language.
I have had good luck in seperating the management tools and the publishing logic in different layers (so far).
First, consider placing the language translation management and generation logic (resource bundles, etc) in the Business Logic. So, for all your translations, you want a way to quickly sync all data entries as they get added to the system in all languages from a master language (english), and then populate and manage those. So, if you're using resource bundles for example, generate the rb files from a database for all the languages.
Second, publish the language translations logic at the presentation tier. It has more to do with presentation and formatting. You inevitably will run into issues with localization for dates, times, currencies, etc that you can handle pretty well here. You may or may not build your own library to publish these things as the confines, or flexibility of your programming language may or may not allow.
If you can give more details I'm sure there are other insights available from everyone here.
Good Luck!
Related
I'm in the middle of writing my first web app. Just wondering how the conventions are when it comes to REST API designs. Is it better to have it reflect my server side architecture or whatever seems to be easier to reason about?
I'm thinking of either doing:
/serviceProvider/product
or
/product/serviceProvider
My server side architecture are all separated into modules organized by service providers, however they all expose a product query API.
APIs ideally should be designed to make most sense for its consumer. There isn't really a good reason to reflect your "server architecture" at all. In fact, it's what's usually called a leaky abstraction or a leaky API and is considered bad practice, mainly because your application structure may change and then you have these possible scenarios:
you need to change your API, which is a non-trivial task when it's already being used by someone;
your API stops being reflective of your application structure which leads to inconsistencies;
exposing your application structure or database schema to the world may have security implications.
With these things in mind, you might as well design the API with focus on ease of use in the first place. The consumer of your API doesn't need to know or care about your application architecture.
I believe that keeping on the same architecture is important because you're forced to offer simple API and it will enforce you a simplified architecture on the server side.
That said, of course that you don't want to expose any server side method or even every server side property of the returned objects.
In Kaltura we also believe in flat (not nested) paths to simplify the API.
For more guidelines, see my blog: http://restafar.com/create-new-rest-server/
I was looking at how you can create a WCF data service around an entity framework context and you can consume it as an EF context as well.
Creating an OData API for StackOverflow including XML and JSON in 30 minutes
I really just started looking at this, but I was wondering where would the business logic go? As a service I would expect that you couldn't just freely add/delete etc without it having some validation.
If I wrote an MVC app to consume this service, how would I best implement business logic. Not simple property level validation that you could do with attributes, but more complex stuff that needs to check the data store first etc.
It sounds like you need a custom data service provider (msdn link). They're quite powerful and give you full control over all of your reading/writing logic.
For example I wrote one that enforces our licensing logic in the update provider.
You can put some in the Data Service class, but you are limited as to what you can and can't do there. And then of course you can put some in the client above the service, but that's not ideal either.
I've only spent a few weeks with WCF Data Services but you highlight (one of) the big problems with it - lack of flexibility. It's fantastic for rapid development and banging out LOB applications, but anything with a deliberate design is very difficult to implement. I needed to include objects in my entity model simply to allow them to be exposed through the service, and I had huge headaches just trying to extend those classes with a simple property.
I'd only recommend using WCF Data Services for trivially simple applications that needed extremely fast development - a one or two day development cycle, for example. Anything else is worth doing thoroughly with regular WCF services, writing your own data layer and so on.
Depending on your specific needs, it sounds like Web API might be a good fit. Web API may never get the full range of OData support that WCF Data Services has, but it does make certain things easier (like adding business logic). I'm quite confident that Web API's initial support for OData will cover a significant number of use cases, and that support will grow over time.
While a custom data provider will most certainly do about anything you want and may well be a great solution for you if you have a complex architecture, I wasn't really thrilled when I attempted to save back through the client and found out I had to implement my the IUpdatable Interface as part of my Context.(I was attempting to build a repository pattern out of my context and DataService).
I'm sure it's very useful for many people, but I really only needed the functionality the EntityProvider already contained and didn't have the time in my project schedule to figure the Iupdatable piece of the custom provider out, so my team, specifically Geoff , stuck with the Entity Provider and used Change and Query Interceptors to route the DataService requests through our Business Logic classes on the server. It provides a central point of control. We used these to provide security checks, run calculations and other operations on Insert/Update, etc. Turned out great. You can also use service methods as another way to provide specific business logic functions to your clients.
I'm in the situation that I have to design and implement a system from the scratch. I have some questions about the architecture that I would like your comments and thoughts on.
Quick Info about the project: It's a data centric web application.
The application will be built on Microsoft .NET Framework 4.0 with MS SQL SERVER 2008 database.
Requirement:
Rich UI and robust
Multi-device support (every browser and on every device)
Loosely coupled
Below is the architectural diagram I have built:
Briefing of the architecture
Presentation layer : HTML5/ASP.NET MVC + JQuery (Web application for multi-device support in first version)
Distributed Services : WCF (XML/JSON/JSONP)
Domain Layer(Business Layer) : All business logic
Data persistence (DAL Layer) : Entity Framework 4.0 with database first approach. POCO entities are generated and separated out using T4 template
Infrastructural Layer: Contains common libraries like POCO entities, Exception Handling, logging etc
My Concerns :
As application is to be built loosely coupled so in future if business requirement grows new modules can be easily plugged in without affecting the architecture.
So I thought of using the Repository pattern along with IoC and DI (can be Unity/Ninject/Sprint.NET or any other)
WCF with both XML and JSON support
Distributed Service Layer to place IoC & DI
Exception Handling & Logging using Enterprise Library 5.0
Looking for valuable comments and suggestions.
If I am doing anything wrong please put me in right direction.
I would suggest the following comment: right from the outset your approach will create tight coupling. This goes directly against your requirement #3 "Loosely coupled"
In your diagram you have defined two modules. Main module, and Module 2. I would guess that these two modules are quite distinct from each other. What I mean by this is that you could develop them completely separately and then plug them in, because the business concerns they address are different.
However, your current architectural approach:
Couples Main Module and Module 2 data into the same database
Couples Main Module and Module 2 business objects into the same business layer
Couples Main Module and Module 2 services into the same service layer
Couples the deployment and management of Main Module and Module 2
What may be worth considering: Build Main Module and Module 2 as separate vertical service stacks.
What I mean is Main Module and Module 2 become Main Service and Service 2
Each service has it's own database, it's own business layer, it's own services layer and it's own UI components.
However, this raises the concern: how can Main Service and Service 2 both work together to create my product?
To address this:
At the UI end, you stitch your front end together by using client-side code to load responses from the Main Service and Service 2 into one view.
At the back end you use publish subscribe messaging to allow Main Service to subscribe to events happening in Service 2 and vice versa.
This will result in an application built from the ground up on top of loosely coupled vertical service stacks, which maintain consistency by the asynchronous exchange of messages.
If you then need to add in a new module to your application, you can create a new service stack which supports the desired capability and wire it up with little or even no change needed to the other stacks (ideally the only reason to change existing stacks would be that they want to subscribe to events from the new module).
It's a very different approach to the one you're suggesting, but one which allows you to meet the requirement for loose coupling better, in my opninion.
How come that the architecture diagram doesn't use the domain layer for ASP.NET?
It seems to me that you may be overarchitecturing your application. Also, while it looks great to support 6 (or so) different front-end technologies, the effort to maintain all of them will be horrendous. I'd stick to one technology for the front-end - most likely HTML5 with client-side MVC or similar.
It makes sense that the WPF, WinForm etc UIs should call the WCF layer. I'm assuming that it's a business requirement to have multiple UIs, otherwise if you can only have one UI a responsive web UI is the most flexible choice.
However, I don't think your MVC UI needs to use the WCF layer. It could call the domain layer directly. That would be faster and remove a pointless layer.
Obviously, that would only work so long as you don't put any logic in your WCF layer. And the WCF layer really shouldn't have any logic in it.
You also state that you want to place IoC & DI in the Distributed Service Layer. That doesn't make much sense in terms of your MVC UI. You'll need to use DI in the MVC project so you can unit test the controllers.
Looking at your diagram I have a couple of points I'm not clear on:
Where is the domain model? Domain Core or the 'model' in the persistence layer?
How does the domain layer interact with the data access layer? The interaction is not as clear as between the service/application layer and domain layer.
What the difference between a repository in the domain layer and a repository in the data access layer? I usually make the distinction of having 'model repositories' in the domain layer which act upon domain model objects, and 'data gateways' in the data access layer which act upon DTO's.
What is domain core? Is this the implementation of the application layer transactions?
Does there need to be a further abstraction of the persistence framework? (EF)
I am working on a packaged product that is supposed to cater to multiple clients with varying requirements (to a certain degree) and as such should be built in a manner to be flexible enough to be customizable by each specific client. The kind of customization we are talking about here is that different client's may have differing attributes for some of the key business objects. Also, they could have differing business logic tied in with their additional attributes as well
As an very simplistic example: Consider "Automobile" to be a business entity in the system and as such has 4 key attributes i.e. VehicleNumber, YearOfManufacture, Price and Colour.
It is possible that one of the clients using the system adds 2 more attributes to Automobile namely ChassisNumber and EngineCapacity. This client needs some business logic associated with these fields to validate that the same chassisNumber doesnt exist in the system when a new Automobile gets added.
Another client just needs one additional attribute called SaleDate. SaleDate has its own business logic check which validates if the vehicle doesnt exist in some police records as a stolen vehicle when the sale date is entered
Most of my experience has been in mostly making enterprise apps for a single client and I am really struggling to see how I could handle a business entity whose attributes are dynamic and also has a capacity for having dynamic business logic as well in an object oriented paradigm
Key Issues
Are there any general OO principles/patterns that would help me in tackling this kind of design?
I am sure people who have worked on generic / packaged products would have faced similar scenarios in most of them. Any advice / pointers / general guidance is also appreciated.
My technology is .NET 3.5/ C# and the project has a layered architecture with a business layer that consists of business entities that encompass their business logic
This is one of our biggest challenges, as we have multiple clients that all use the same code base, but have widely varying needs. Let me share our evolution story with you:
Our company started out with a single client, and as we began to get other clients, you'd start seeing things like this in the code:
if(clientName == "ABC") {
// do it the way ABC client likes
} else {
// do it the way most clients like.
}
Eventually we got wise to the fact that this makes really ugly and unmanageable code. If another client wanted theirs to behave like ABC's in one place and CBA's in another place, we were stuck. So instead, we turned to a .properties file with a bunch of configuration points.
if((bool)configProps.get("LastNameFirst")) {
// output the last name first
} else {
// output the first name first
}
This was an improvement, but still very clunky. "Magic strings" abounded. There was no real organization or documentation around the various properties. Many of the properties depended on other properties and wouldn't do anything (or would even break something!) if not used in the right combinations. Much (possibly even most) of our time in some iterations was spent fixing bugs that arose because we had "fixed" something for one client that broke another client's configuration. When we got a new client, we would just start with the properties file of another client that had the configuration "most like" the one this client wanted, and then try to tweak things until they looked right.
We tried using various techniques to get these configuration points to be less clunky, but only made moderate progress:
if(userDisplayConfigBean.showLastNameFirst())) {
// output the last name first
} else {
// output the first name first
}
There were a few projects to get these configurations under control. One involved writing an XML-based view engine so that we could better customize the displays for each client.
<client name="ABC">
<field name="last_name" />
<field name="first_name" />
</client>
Another project involved writing a configuration management system to consolidate our configuration code, enforce that each configuration point was well documented, allow super users to change the configuration values at run-time, and allow the code to validate each change to avoid getting an invalid combination of configuration values.
These various changes definitely made life a lot easier with each new client, but most of them failed to address the root of our problems. The change that really benefited us most was when we stopped looking at our product as a series of fixes to make something work for one more client, and we started looking at our product as a "product." When a client asked for a new feature, we started to carefully consider questions like:
How many other clients would be able to use this feature, either now or in the future?
Can it be implemented in a way that doesn't make our code less manageable?
Could we implement a different feature that what they are asking for, which would still meet their needs while being more suited to reuse by other clients?
When implementing a feature, we would take the long view. Rather than creating a new database field that would only be used by one client, we might create a whole new table which could allow any client to define any number of custom fields. It would take more work up-front, but we could allow each client to customize their own product with a great degree of flexibility, without requiring a programmer to change any code.
That said, sometimes there are certain customizations that you can't really accomplish without investing an enormous effort in complex Rules engines and so forth. When you just need to make it work one way for one client and another way for another client, I've found that your best bet is to program to interfaces and leverage dependency injection. If you follow "SOLID" principles to make sure your code is written modularly with good "separation of concerns," etc., it isn't nearly as painful to change the implementation of a particular part of your code for a particular client:
public FirstLastNameGenerator : INameDisplayGenerator
{
IPersonRepository _personRepository;
public FirstLastNameGenerator(IPersonRepository personRepository)
{
_personRepository = personRepository;
}
public string GenerateDisplayNameForPerson(int personId)
{
Person person = _personRepository.GetById(personId);
return person.FirstName + " " + person.LastName;
}
}
public AbcModule : NinjectModule
{
public override void Load()
{
Rebind<INameDisplayGenerator>().To<FirstLastNameGenerator>();
}
}
This approach is enhanced by the other techniques I mentioned earlier. For example, I didn't write an AbcNameGenerator because maybe other clients will want similar behavior in their programs. But using this approach you can fairly easily define modules that override default settings for specific clients, in a way that is very flexible and extensible.
Because systems like this are inherently fragile, it is also important to focus heavily on automated testing: Unit tests for individual classes, integration tests to make sure (for example) that your injection bindings are all working correctly, and system tests to make sure everything works together without regressing.
PS: I use "we" throughout this story, even though I wasn't actually working at the company for much of its history.
PPS: Pardon the mixture of C# and Java.
That's a Dynamic Object Model or Adaptive Object Model you're building. And of course, when customers start adding behaviour and data, they are programming, so you need to have version control, tests, release, namespace/context and rights management for that.
A way of approaching this is to use a meta-layer, or reflection, or both. In addition you will need to provide a customisation application which will allow modification, by the users, of your business logic layer. Such a meta-layer does not really fit in your layered architecture - it is more like a layer orthoganal to your existing architecture, though the running application will probably need to refer to it, at least on initialisation. This type of facility is probably one of the fastest ways of screwing up the production application known to man, so you must:
Ensure that the access to this editor is limited to people with a high level of rights on the system (eg administrator).
Provide a sandbox area for the customer modifications to be tested before any changes they are testing are put on the production system.
An "OOPS" facility whereby they can revert their production system to either your provided initial default, or to the last revision before the change.
Your meta-layer must be very tightly specified so that the range of activities is closely defined - George Orwell's "What is not specifically allowed, is forbidden."
Your meta-layer will have objects in it such as Business Object, Method, Property and events such as Add Business Object, Call Method etc.
There is a wealth of information about meta-programming available on the web, but I would start with Pattern Languages of Program Design Vol 2 or any of the WWW resources related to, or emanating from Kent or Coplien.
We develop an SDK that does something like this. We chose COM for our core because we were far more comfortable with it than with low-level .NET, but no doubt you could do it all natively in .NET.
The basic architecture is something like this: Types are described in a COM type library. All types derive from a root type called Object. A COM DLL implements this root Object type and provides generic access to derived types' properties via IDispatch. This DLL is wrapped in a .NET PIA assembly because we anticipate that most developers will prefer to work in .NET. The Object type has a factory method to create objects of any type in the model.
Our product is at version 1 and we haven't implemented methods yet - in this version business logic must be coded into the client application. But our general vision is that methods will be written by the developer in his language of choice, compiled to .NET assemblies or COM DLLs (and maybe Java too) and exposed via IDispatch. Then the same IDispatch implementation in our root Object type can call them.
If you anticipate that most of the custom business logic will be validation (such as checking for duplicate chassis numbers) then you could implement some general events on your root Object type (assuming you did it something like the way we do.) Our Object type fires an event whenever a property is updated, and I suppose this could be augmented by a validation method that gets called automatically if one is defined.
It takes a lot of work to create a generic system like this, but the payoff is that application development on top of the SDK is very quick.
You say that your customers should be able to add custom properties and implement business logic themselves "without programming". If your system also implements data storage based on the types (ours does) then the customer could add properties without programming, by editing the model (we provide a GUI model editor.) You could even provide a generic user application that dynamically presents the appropriate data-entry controls depending on the types, so your customers could capture custom data without additional programming. (We provide a generic client application but it's more a developer tool than a viable end-user application.) I don't see how you could allow your customers to implement custom logic without programming... unless you want to provide some kind of drag-n-drop GUI workflow builder... surely a huge task.
We don't envisage business users doing any of this stuff. In our development model all customisation is done by a developer, but not necessarily an expensive one - part of our vision is to allow less experienced developers produce robust business applications.
Design a core model that acts as its own independent project
Here's a list of some possible basic requirements...
The core design would contain:
classes that work (and possibly be extended) in all of the subprojects.
more complex tools like database interactions (unless those are project specific)
a general configuration structure that should be considered standard across all projects
Then, all of the subsequent projects that are customized per client are considered extensions of this core project.
What you're describing is the basic purpose of any Framework. Namely, create a core set of functionality that can be set apart from the whole so you don't have to duplicate that development effort in every project you create. Ie, drop in a framework and half your work is done already.
You might say, "what about the SCM (Software Configuration Management)?"
How do you track revision history of all of the subprojects without including the core into the subproject repository?
Fortunately, this is an old problem. Many software projects, especially those in the the linux/open source world, make extensive use of external libraries and plugins.
In fact git has a command that's specifically used to import one project repository into another as a sub-repository (preserving all of the sub-repository's revision history etc). In fact, you can't modify the contents of the sub-repository because the project won't track it's history at all.
The command I'm talking about is called 'git submodule'.
You may ask, "what if I develop a really cool feature in one client's project that I'd like to use in all of my client's projects?".
Just add that feature to the core and run a 'git submodule sync' on all the other projects. The way git submodule works is, it points to a specific commit within the sub-repository's history tree. So, when that tree is changed upstream, you need to pull those changes back downstream to the projects where they're used.
The structure to implement such a thing would work like this. Lets say that you software is written specifically to manage a car dealership (inventory, sales, employees, customers, orders, etc...). You create a core module that covers all of these features because they are expected to be used in the software for all of your clients.
But, you have recently gained a new client who wants to be more tech savvy by adding online sales to their dealership. Of course, their website is designed by a separate team of web developers/designers and webmaster but they want a web API (Ie, service layer) to tap into the current infrastructure for their website.
What you'd do is create a project for the client, we'll call it WebDealersRUs and link the core submodule into the repository.
The hidden benefit of this is, once you start to look as a codebase as pluggable parts, you can start to design them from the start as modular pieces that are capable of being dropped in to a project with very little effort.
Consider the example above. Lets say that your client base is starting to see the merits of adding a web-front to increase sales. Just pull the web API out of the WebDealersRUs into its own repository and link it back in as a submodule. Then propagate to all of your clients that want it.
What you get is a major payoff with minimal effort.
Of course there will always be parts of every project that are client specific (branding, ect). That's why every client should have a separate repository containing their unique version of the software. But that doesn't mean that you can't pull parts out and generalize them to be reused in subsequent projects.
While I approach this issue from the macro level, it can be applied to smaller/more specific parts of the codebase. The key here is code that you wish to re-use needs to be genericized.
OOP comes into play here because: where the functionality is implemented in the core but extended in client's code you'll use a base class and inherit from it; where the functionality is expected to return a similar type of result but the implementations of that functionality may be wildly different across classes (Ie, there's no direct inheritance hierarchy) it's best to use an interface to enforce that relationship.
I know your question is general, not tied to a technology, but since you mention you actually work with .NET, I suggest you look at a new and very important technology piece that is part of .NET 4: the 'dynamic' type.
There is also a good article on CodeProject here: DynamicObjects – Duck-Typing in .NET.
It's probably worth to look at, because, if I have to implement the dynamic system you describe, I would certainly try to implement my entities based on the DynamicObject class and add custom properties and methods using the TryGetxxx methods. It also depends whether you are focused on compile time or runtime. Here is an interesting link here on SO: Dynamically adding members to a dynamic object on this subject.
Two approaches is what I feel:
1) If different clients fall on to same domain (as Manufacturing/Finance) then it's better to design objects in such a way that BaseObject should have attributes which are very common and other's which could vary in between clients as key-value pairs. On top of it, try to implement rule engine like IBM ILog(http://www-01.ibm.com/software/integration/business-rule-management/rulesnet-family/about/).
2) Predictive Model Markup Language(http://en.wikipedia.org/wiki/PMML)
Using VB.NET 2008
I want to know what is 3 Tier Architecture for windows application?
Can any one give a example of How to make a code for Inserting, Deleting, Updating in a database using 3 tier architecture.
Note am not asking a real code. Just give me a example.
From Multitier architecture
Three-tier'[2] is a client-server
architecture in which the user
interface, functional process logic
("business rules"), computer data
storage and data access are developed
and maintained as independent modules,
most often on separate platforms.
These days, a normal 3 tier application consists of a user interface written in Javascript, CSS and HTML which runs in the browser, a business rules layer which runs in a web server, and could indeed be built in VB.NET, and a storage layer which runs on a database server written in SQL and stored procedures.
Now it would be possible to do a user interface layer in VB.NET as a Windows application which then calls the business rules layer on the web server using a web services interface. This would give you more flexibility than the browser, and would not require learning as many APIs, however it is not common. It can really only be done in an enterprise situation.
This article has a simple VB.NET application that is a Windows GUI app, which call Google's web services API to do searches and to check spelling. That is a good example of a user interface layer. Then check this article for and exmple of a web service developed in VB.NET. This corresponds to the business rules layer, and in a real 3-tier application, it would be based around a database such as SQL server. If you were to use Access then it would not be a real 3-tier application. The database needs to be run on its own server and accessed across the network in order to be considered a tier.
The advantage of a 3-tier application is that you can scale each layer separately, and because each layer is simpler, scaling is also simpler. The DBAs can scale up to a database cluster, the business rules layer can scale up with a load-balancer and multiple servers, and the user-interface just gets replicated across as many clients as you need.
I don't know if is it the right way to use it, but I often use 3-tier int the following way:
One big Solution, with the name of the project
One dll project wich has the conection with the DB, using LINQ or whathever. Validating only the required fields of the DB
Another DLL project, wich has a reference to the project that conects to DB, and validate all data using the bussiness rules. Sometimes you may want a repositorium class wich has methods that can be used from the GUI layer
Finally, the GUI layer that can be HTML or WINForms, wich references to the bussines layer and calls all the appropiates methods, passing the data transparently and waiting for validation on the bussines rules.
You can comunicate with each layer using bool methods that returns true if everything is good, and personalized exceptions for each of the possible errors, and catch them on the upper layer.
I'll give you the gist of it. Real crash course.
You have three tiers:
DAL - Data Access Layer
BRL - Business Rule Layer
Presentation - The Forms, and such.
In the DAL, you configure how your application connects to databases, how it recieves datasets, etc. etc. Everything that has to do with data access.
In the BRL, you lay down how your program is going to handle the data it recieves from the DAL. Methods, and other things go in here.
And in the Presentation area, you simply make things purty and instantiate things from the BRL. The presentation area never has to touch the DAL, and that's the beauty of the 3tier layout. You can work on different areas and not step on other peoples toes.
I find the best way to understand it is to look at an example. If you go here:
http://www.codeproject.com/KB/vb/N-Tier_Application_VB.aspx
You can download an example and read the walk through for creating a very basic 3 Tier App in VB.Net. It's a little old in that it's a Visual Studio 2003 project but it should be easy enough to follow the upgrade wizard and get it up and running to check it out.
I'd like to give a brief overview about this style of programming and maybe I'll explain it in more details next time.
First of all, the 3-Tire concept engages dividing your program or application you are designing into 3 layers, the first layer is for manipulating the database in the operation called CRUD which stands for {Create,Read,Update,Delete} data from your database, using any kind of Databases : for example Oracle,SQLserver,MySql etc. That means you can connect your application with any type of databases without specifying a connection String to Only one database and we'll get more details about this next time.
The Second layer is Business layer which includes user data verification and other similar operations in which you process your business rules and the core of program,
The Third and Last layer is the Presentation layer which relates to User input and UI User Interfaces {The different forms for Input}
Frankly you can divide your Solution {Program,Application,Website} to sub-Programs to avoid data loss,organize your work, and to divide the development of your application among a team members.
in my point of view this is a great thing should be learnt in development, and as I was told by the grapeVine, if you want to enrich your knowledge and experience then you should be acknowledged about this important subject.