Architectural question (crisis)
-
Hi everyone, i'm having a bit of an architectural crisis. I want to start an application that is layered. I cannot use datasets, only an object model. I want the following layers: DAL, Common, Services, facade(not nessessary), and web/webservices. Where do i put the object model (objects like customer, questionlists, employees,...). In the common layer so i can get filled employee's out of the DAL or do i put the OM in the services layer and fill them there? The first has the advantage that i only need my update delete and insert take 1 parameter (employee) otherwise with the OM in the services layer i need my DAL funtions to take all the parameters. What do you do? Thank you Jan Vercauteren. OVERVIEW -----------------------------|---------------| | DAL | | -----------------------------| | | SERVICES | COMMON | |----------------------------| | | FACADE | | |----------------------------| | | GUI (web) | | |----------------------------|---------------| www.agilis.be
-
Hi everyone, i'm having a bit of an architectural crisis. I want to start an application that is layered. I cannot use datasets, only an object model. I want the following layers: DAL, Common, Services, facade(not nessessary), and web/webservices. Where do i put the object model (objects like customer, questionlists, employees,...). In the common layer so i can get filled employee's out of the DAL or do i put the OM in the services layer and fill them there? The first has the advantage that i only need my update delete and insert take 1 parameter (employee) otherwise with the OM in the services layer i need my DAL funtions to take all the parameters. What do you do? Thank you Jan Vercauteren. OVERVIEW -----------------------------|---------------| | DAL | | -----------------------------| | | SERVICES | COMMON | |----------------------------| | | FACADE | | |----------------------------| | | GUI (web) | | |----------------------------|---------------| www.agilis.be
Hmmm...4 tier architecture? What is facade layer, anyways? Jan Vercauteren wrote: want to start an application that is layered. I cannot use datasets, only an object model. I want the following layers: DAL, Common, Services, facade(not nessessary), and web/webservices What do you mean by common layer?? Well, you could use the collection objects in your services. You can combine objects and services in the service layer.
WEB -- Front End
WEB -- FACADE
WEB -- SERVICES | COMMON
WEB -- Front End
-
Hi everyone, i'm having a bit of an architectural crisis. I want to start an application that is layered. I cannot use datasets, only an object model. I want the following layers: DAL, Common, Services, facade(not nessessary), and web/webservices. Where do i put the object model (objects like customer, questionlists, employees,...). In the common layer so i can get filled employee's out of the DAL or do i put the OM in the services layer and fill them there? The first has the advantage that i only need my update delete and insert take 1 parameter (employee) otherwise with the OM in the services layer i need my DAL funtions to take all the parameters. What do you do? Thank you Jan Vercauteren. OVERVIEW -----------------------------|---------------| | DAL | | -----------------------------| | | SERVICES | COMMON | |----------------------------| | | FACADE | | |----------------------------| | | GUI (web) | | |----------------------------|---------------| www.agilis.be
Hmmm...4 tier architecture? What is facade layer, anyways? Jan Vercauteren wrote: want to start an application that is layered. I cannot use datasets, only an object model. I want the following layers: DAL, Common, Services, facade(not nessessary), and web/webservices What do you mean by common layer?? Well, you could use the collection objects in your services. You can combine objects and services in the service layer.
-
Hmmm...4 tier architecture? What is facade layer, anyways? Jan Vercauteren wrote: want to start an application that is layered. I cannot use datasets, only an object model. I want the following layers: DAL, Common, Services, facade(not nessessary), and web/webservices What do you mean by common layer?? Well, you could use the collection objects in your services. You can combine objects and services in the service layer.
Facade layer is a sort of "grouping" layer. Lets say you have a customer and a orderEmployee. A customer can add an order a orderEmpoyee can add an order and approve orders. You have an order object wich has the 2 functions + a couple of internal ones. You create a customer facade with only te first operation in it and a orderEmployee facade with both in it. This makes an application easier to secure and to understand for other people. This looks not nessessary but if you have 10+ roles and 50 objects and then times the amount of functions witch are not all to be exposed to the client... jan www.agilis.be
-
Hi everyone, i'm having a bit of an architectural crisis. I want to start an application that is layered. I cannot use datasets, only an object model. I want the following layers: DAL, Common, Services, facade(not nessessary), and web/webservices. Where do i put the object model (objects like customer, questionlists, employees,...). In the common layer so i can get filled employee's out of the DAL or do i put the OM in the services layer and fill them there? The first has the advantage that i only need my update delete and insert take 1 parameter (employee) otherwise with the OM in the services layer i need my DAL funtions to take all the parameters. What do you do? Thank you Jan Vercauteren. OVERVIEW -----------------------------|---------------| | DAL | | -----------------------------| | | SERVICES | COMMON | |----------------------------| | | FACADE | | |----------------------------| | | GUI (web) | | |----------------------------|---------------| www.agilis.be
Hello Jan. The major reason for a DAL is data abstraction; it should deliver data to your application in a data source-independant way. Your OM contains the data transport classes that the DAL uses to deliver data to the service layer, so the OM should rest inside the DAL. The DAL should also contain factory/accessor classes that connects to data sources, obtains data, instantiates OM classes and fills them with the data and delivers them to the service layer. The "Common" is not needed. Regards, Björn Morén Stockholm, Sweden
-
Hello Jan. The major reason for a DAL is data abstraction; it should deliver data to your application in a data source-independant way. Your OM contains the data transport classes that the DAL uses to deliver data to the service layer, so the OM should rest inside the DAL. The DAL should also contain factory/accessor classes that connects to data sources, obtains data, instantiates OM classes and fills them with the data and delivers them to the service layer. The "Common" is not needed. Regards, Björn Morén Stockholm, Sweden
Hi Björn Thank you for the reply. I asked this because msdn is screaming black and white about the subject of custom objects. The say put the creation static in the objects, who then ask the dal to create them. Or put the objects in the DAL like you do. Or use a common layer. Do you have an example or uml scheme? Another question: Insert update and delete, are those methods inside the custom object? Thank you (to respond the the question above this post: a common layer holds classes that can be used in all layers) www.agilis.be
-
Hi Björn Thank you for the reply. I asked this because msdn is screaming black and white about the subject of custom objects. The say put the creation static in the objects, who then ask the dal to create them. Or put the objects in the DAL like you do. Or use a common layer. Do you have an example or uml scheme? Another question: Insert update and delete, are those methods inside the custom object? Thank you (to respond the the question above this post: a common layer holds classes that can be used in all layers) www.agilis.be
The deal with statics that's been on the MSDN site for a while is for a provider pattern. Basically, you have an abstract class with a static method that reads providers from, say, a .config file and creates instances of those classes (that derive from the abstract base class) and return the instance as an abstract base class, something like the following pseudo-code:
public abstract class DataProviderBase
{
// Logical instance methods, like those to get and set data, information
// about the provider, etc.
public static DataProviderBase GetProvider()
{
// Read provider configuration from .config file that must extend
// this abstract base class and return it.
return GetProviderFromConfig();
}
}There is an article posted recently on MSDN that goes into greater depth: Provider Model Design Pattern and Specification, Part 1[^].
Microsoft MVP, Visual C# My Articles
-
The deal with statics that's been on the MSDN site for a while is for a provider pattern. Basically, you have an abstract class with a static method that reads providers from, say, a .config file and creates instances of those classes (that derive from the abstract base class) and return the instance as an abstract base class, something like the following pseudo-code:
public abstract class DataProviderBase
{
// Logical instance methods, like those to get and set data, information
// about the provider, etc.
public static DataProviderBase GetProvider()
{
// Read provider configuration from .config file that must extend
// this abstract base class and return it.
return GetProviderFromConfig();
}
}There is an article posted recently on MSDN that goes into greater depth: Provider Model Design Pattern and Specification, Part 1[^].
Microsoft MVP, Visual C# My Articles
I just want to know where to put the object model (the classes like customers, orders, ...) in the n-tier model. Common , Data or business layer. (on msdn they put datasets is the common. thanks Jan www.agilis.be
-
I just want to know where to put the object model (the classes like customers, orders, ...) in the n-tier model. Common , Data or business layer. (on msdn they put datasets is the common. thanks Jan www.agilis.be
I'd prefer to put the object model you refer to in the DAL and use the provider pattern for those objects to get/set data in a data source (such as a database), effectively splitting up the data layer into two tiers (although that depends on your scope of a tier). The business layer typically defines how those objects interact with each other. Again, depending on your view of what comprises a tier, you might consider that those objects are either in the business layer or the data layer. Also keep in mind that N-tier isn't limited to 3 tiers. For example, our next major version of our application that is currently being sketched out consists of many layers, such as a presentation layer, a business layer, a data objects layer coupled with a data provider layer, with a server layer to provide remotable data services for our implementation (while other companies can choose to override or replace whatever layer they want). It's a pretty fractured design, but a pretty big N-tier model allowing for maximum (IMO) extensibility.
Microsoft MVP, Visual C# My Articles
-
Hi Björn Thank you for the reply. I asked this because msdn is screaming black and white about the subject of custom objects. The say put the creation static in the objects, who then ask the dal to create them. Or put the objects in the DAL like you do. Or use a common layer. Do you have an example or uml scheme? Another question: Insert update and delete, are those methods inside the custom object? Thank you (to respond the the question above this post: a common layer holds classes that can be used in all layers) www.agilis.be
I'm sure there are many ways to solve this, and much has to do with taste. For most applications I prefer a 3-tier solution: data, business and facade/presentation, but that is of course depending a lot on the scenario. The data tier consists of two kinds of classes, none of them static: 1. The objects in the object model (usually maps to tables in a relational database). Those are very much like structures, with no logic in them, just data fields for transport. For example the Customer class. Take a look at xsd.exe to generate those out of schemas. 2. Factory/accessor classes that creates and delivers object model instances, or recieves object model instances. For example CustomerFactory (or CustomerDB if you don't like the "concrete factory" pattern analogy). Those classes contain logic for retrieving data and updating data. If the data resides in SQL server they handle connection objects and have all the insert, update and select in them (or SP's handle that). If the data comes from a web service, they contain web service consumer proxies etc. Example of methods: public Customer FindByCustomerID(int id) public OperationResult Save(Customer[] customers) I think the most important design decision for you to consider is that the data-tier should not be aware of the other tiers, and it shall reveal nothing about the actual data sources to the other tiers. It delivers the data to whoever needs it, period. Much more can be said about the details, and many books have been written on the subject. Good luck with your project. Regards, Björn Morén Stockholm, Sweden
-
I'm sure there are many ways to solve this, and much has to do with taste. For most applications I prefer a 3-tier solution: data, business and facade/presentation, but that is of course depending a lot on the scenario. The data tier consists of two kinds of classes, none of them static: 1. The objects in the object model (usually maps to tables in a relational database). Those are very much like structures, with no logic in them, just data fields for transport. For example the Customer class. Take a look at xsd.exe to generate those out of schemas. 2. Factory/accessor classes that creates and delivers object model instances, or recieves object model instances. For example CustomerFactory (or CustomerDB if you don't like the "concrete factory" pattern analogy). Those classes contain logic for retrieving data and updating data. If the data resides in SQL server they handle connection objects and have all the insert, update and select in them (or SP's handle that). If the data comes from a web service, they contain web service consumer proxies etc. Example of methods: public Customer FindByCustomerID(int id) public OperationResult Save(Customer[] customers) I think the most important design decision for you to consider is that the data-tier should not be aware of the other tiers, and it shall reveal nothing about the actual data sources to the other tiers. It delivers the data to whoever needs it, period. Much more can be said about the details, and many books have been written on the subject. Good luck with your project. Regards, Björn Morén Stockholm, Sweden
Thanks Björn I had just read the "mastering XDE book from sybex" It had an overview of different patterns but i just couldn't fit the puzzle together. Now it's coming clear to me. If you ever need a favor, just yell Greets from Belgium Jan www.agilis.be