tiered development discussion question
-
So I have a question. We all know about 3-tier or n-tier development, and how great it is to separate the presentation layer from the business layer and the data access layer. My question is, how have you gone about doing that separation? No, this isn't a "how do you do it?", it's a "from projects you've worked on, how well have you achieved that separation?" and "what specific technique did you employee?" question. There's lots of ways to create this separation--messaging, mediator objects (among other design patterns), interfaces, etc. What techniques do you like? What works for you? What compromises do you make? The reason I'm asking is because I have my own techniques but I've never had any formal education in this area (or any area, for that matter). I'm curious what they are teaching people. Or is this just cultural wisdom that gets somehow transmitted to the next generation? I'm also asking because I went to bed last night realizing that the issues with n-tier development apply also to declarative programming. I woke up even more strongly convinced of this. More on this later. (And yes, I've read the Microsoft articles on tiered development, etc. Theory is great). Marc MyXaml Advanced Unit Testing YAPO
-
So I have a question. We all know about 3-tier or n-tier development, and how great it is to separate the presentation layer from the business layer and the data access layer. My question is, how have you gone about doing that separation? No, this isn't a "how do you do it?", it's a "from projects you've worked on, how well have you achieved that separation?" and "what specific technique did you employee?" question. There's lots of ways to create this separation--messaging, mediator objects (among other design patterns), interfaces, etc. What techniques do you like? What works for you? What compromises do you make? The reason I'm asking is because I have my own techniques but I've never had any formal education in this area (or any area, for that matter). I'm curious what they are teaching people. Or is this just cultural wisdom that gets somehow transmitted to the next generation? I'm also asking because I went to bed last night realizing that the issues with n-tier development apply also to declarative programming. I woke up even more strongly convinced of this. More on this later. (And yes, I've read the Microsoft articles on tiered development, etc. Theory is great). Marc MyXaml Advanced Unit Testing YAPO
This could lead to a whole article, but what I did: For the Data layer (actually, the most complex): 1. Create interfaces for the major DB entities (IUser, ICustomer, etc), and all the queries on them are methods. Notice that I refer to 'entities', not 'tables'. 2. Implement those interfaces for each DBMS supported. 3. Create a class (often with the creative name 'Data'), which holds a singleton for each class. So, I access my DB as Data.Customer.ListAll(). In this case, Data.Customer is a static property that returns ICustomer. On the static constructor, Data initializes all the singletons to the proper DBMS. 4. Only return typed data from the data layer (primitives, classes, and God forbids, typed datasets) Actually, this layer is a bit more complex, as it needs to deal with connection strings, multiple databases (my solution integrates a lot of different databases). It also needs to deal with database field encryption (I know, it's stupid and only feels secure, but some companies explicitly asked for this). For the Business Rules and the Evaluation Engine (the last one is a layer that my solution needs that is on the same level as the BR): 1. All data access is done through the data layer (actually, it's pretty natural, otherwise it would need to implement it for a couple of different DBMS) 2. Everything that is not interface-specific goes on these two layers. For the UI layer, we have a few different interfaces, so: 1. Web 2. SOAP 3. COM 4. Sockets 5. Desktop application 6. File exchange (I'll go to purgatory for 200 years because of this) All the interface components provide the same services, and, e.g., everything an user can do using the Web interface is available on the programatic interfaces (COM, sockets, SOAP, etc). So, when you have lots of different interfaces, it's pretty easy to understand on which layer you should put some piece of code (e.g., a validation). I see dead pixels Yes, even I am blogging now!
-
So I have a question. We all know about 3-tier or n-tier development, and how great it is to separate the presentation layer from the business layer and the data access layer. My question is, how have you gone about doing that separation? No, this isn't a "how do you do it?", it's a "from projects you've worked on, how well have you achieved that separation?" and "what specific technique did you employee?" question. There's lots of ways to create this separation--messaging, mediator objects (among other design patterns), interfaces, etc. What techniques do you like? What works for you? What compromises do you make? The reason I'm asking is because I have my own techniques but I've never had any formal education in this area (or any area, for that matter). I'm curious what they are teaching people. Or is this just cultural wisdom that gets somehow transmitted to the next generation? I'm also asking because I went to bed last night realizing that the issues with n-tier development apply also to declarative programming. I woke up even more strongly convinced of this. More on this later. (And yes, I've read the Microsoft articles on tiered development, etc. Theory is great). Marc MyXaml Advanced Unit Testing YAPO
Marc Clifton wrote: tiered development discussion question I read that as tired development discussion. Doh. Michael CP Blog [^] Development Blog [^]
-
Marc Clifton wrote: tiered development discussion question I read that as tired development discussion. Doh. Michael CP Blog [^] Development Blog [^]
Michael P Butler wrote: I read that as tired development discussion Well, considering this: Marc Clifton wrote: what specific technique did you employee? it might be ;) [edit]This was meant to be a reply to Michael's message... In fact, this is the first message I've seen where the reply was posted before the original message. Woah... :~ [/edit]
Ryan
"Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"
-
So I have a question. We all know about 3-tier or n-tier development, and how great it is to separate the presentation layer from the business layer and the data access layer. My question is, how have you gone about doing that separation? No, this isn't a "how do you do it?", it's a "from projects you've worked on, how well have you achieved that separation?" and "what specific technique did you employee?" question. There's lots of ways to create this separation--messaging, mediator objects (among other design patterns), interfaces, etc. What techniques do you like? What works for you? What compromises do you make? The reason I'm asking is because I have my own techniques but I've never had any formal education in this area (or any area, for that matter). I'm curious what they are teaching people. Or is this just cultural wisdom that gets somehow transmitted to the next generation? I'm also asking because I went to bed last night realizing that the issues with n-tier development apply also to declarative programming. I woke up even more strongly convinced of this. More on this later. (And yes, I've read the Microsoft articles on tiered development, etc. Theory is great). Marc MyXaml Advanced Unit Testing YAPO
I think its a bit like asking how long is a piece of string sometimes - and to some extent, I would venture that it can't be taught, hence I dont see your lack of formal qualifications as an issue (nor mine) - sure, you can teach people what things do and why - how to join components/systems together, requires artistry (or sophistry !!), that sometimes you just cant teach. In a recent situation, a high speed message switch, the two main components were seperated themselves by messaging (over TCP/IP, using ACE, a natural choice the design & implementation team thought, since the external communications and some of the internal routes were also TCP/IP based, and using ACE). From the more conventional groups, I received a lot of flak for seperating basically a dumb switch component from a business logic component like this. My reasoning became apparent when we needed to 'split off' one of the communication channels to feed an external analyser - we simply re-defined the channel in-situ (no downtime), ran up another business logic component/engine on another box where the analyser was located, and pointed the new channel to it without interrupting the real-time flow to our mainframe. Try doing that with a tightly coupled , less dynamic/flexible system. It also allows us to expand by running the business logic component(s) on other machines to scale up ... But the system also has for example, an auditing interface via JMS messaging, another interface to an in-memory card-cache table, AND a file based interface for a signalling mechanism - why, becuase the mainframe needed a simple way to tell us to switch to a 24x7 system, and a file based polling interface was the simplest choice. I like your phrase 'cultural wisdom' - a lot of ideas I employed in the messaging project were from such wisdom - while being tempered by a top class c++ (he'll hate me for it) 'guru', Matthew Wilson, who writes for CUJ amongst other things. And I still look at your ideas, on OPEN for example and am guided by the wisdom within....
-
So I have a question. We all know about 3-tier or n-tier development, and how great it is to separate the presentation layer from the business layer and the data access layer. My question is, how have you gone about doing that separation? No, this isn't a "how do you do it?", it's a "from projects you've worked on, how well have you achieved that separation?" and "what specific technique did you employee?" question. There's lots of ways to create this separation--messaging, mediator objects (among other design patterns), interfaces, etc. What techniques do you like? What works for you? What compromises do you make? The reason I'm asking is because I have my own techniques but I've never had any formal education in this area (or any area, for that matter). I'm curious what they are teaching people. Or is this just cultural wisdom that gets somehow transmitted to the next generation? I'm also asking because I went to bed last night realizing that the issues with n-tier development apply also to declarative programming. I woke up even more strongly convinced of this. More on this later. (And yes, I've read the Microsoft articles on tiered development, etc. Theory is great). Marc MyXaml Advanced Unit Testing YAPO
Well, if you consider a 2-tier application... :-D I try to (in most cases) separate out the GUI from the business logic. One app in particular used a homegrown XML scheme to do that. Sorry, it wasn't MyXAML - it didn't exist yet, and C# itself was just in its infancy. But the concepts were somewhat similar. The business rules themselves were also in a separate scripting language, the code was really just the engine that processed those rules. It made for a highly customizable application - we reused this for several products and customers, most of which needed customizations. The generation of random numbers is too important to be left to chance.
-
This could lead to a whole article, but what I did: For the Data layer (actually, the most complex): 1. Create interfaces for the major DB entities (IUser, ICustomer, etc), and all the queries on them are methods. Notice that I refer to 'entities', not 'tables'. 2. Implement those interfaces for each DBMS supported. 3. Create a class (often with the creative name 'Data'), which holds a singleton for each class. So, I access my DB as Data.Customer.ListAll(). In this case, Data.Customer is a static property that returns ICustomer. On the static constructor, Data initializes all the singletons to the proper DBMS. 4. Only return typed data from the data layer (primitives, classes, and God forbids, typed datasets) Actually, this layer is a bit more complex, as it needs to deal with connection strings, multiple databases (my solution integrates a lot of different databases). It also needs to deal with database field encryption (I know, it's stupid and only feels secure, but some companies explicitly asked for this). For the Business Rules and the Evaluation Engine (the last one is a layer that my solution needs that is on the same level as the BR): 1. All data access is done through the data layer (actually, it's pretty natural, otherwise it would need to implement it for a couple of different DBMS) 2. Everything that is not interface-specific goes on these two layers. For the UI layer, we have a few different interfaces, so: 1. Web 2. SOAP 3. COM 4. Sockets 5. Desktop application 6. File exchange (I'll go to purgatory for 200 years because of this) All the interface components provide the same services, and, e.g., everything an user can do using the Web interface is available on the programatic interfaces (COM, sockets, SOAP, etc). So, when you have lots of different interfaces, it's pretty easy to understand on which layer you should put some piece of code (e.g., a validation). I see dead pixels Yes, even I am blogging now!
Thanks for the response! So, if I understand this architecture, the specific UI implementations all access the business layer through interfaces, and the business layer access the data layer through interfaces as well? For example, if you have a Customer GUI (name, address, etc), when the user clicks on "OK" after, say, updating the address, does the GUI update the Data.Customer fields directly in the event handler, or does it call the business layer through something like IBusinessLayer.UpdateCustomer(name, address...), which in turn might do something like Data.Customer.Update()? I hope that question makes sense. :) Marc MyXaml Advanced Unit Testing YAPO
-
So I have a question. We all know about 3-tier or n-tier development, and how great it is to separate the presentation layer from the business layer and the data access layer. My question is, how have you gone about doing that separation? No, this isn't a "how do you do it?", it's a "from projects you've worked on, how well have you achieved that separation?" and "what specific technique did you employee?" question. There's lots of ways to create this separation--messaging, mediator objects (among other design patterns), interfaces, etc. What techniques do you like? What works for you? What compromises do you make? The reason I'm asking is because I have my own techniques but I've never had any formal education in this area (or any area, for that matter). I'm curious what they are teaching people. Or is this just cultural wisdom that gets somehow transmitted to the next generation? I'm also asking because I went to bed last night realizing that the issues with n-tier development apply also to declarative programming. I woke up even more strongly convinced of this. More on this later. (And yes, I've read the Microsoft articles on tiered development, etc. Theory is great). Marc MyXaml Advanced Unit Testing YAPO
Hi, On my current project (first C# project now into year 2), I designed a Data Access Layer that would take a data object (all derived from the same utility base class) and do the ORM. The DAL objects are all remotable and stateless so they can live near the DB and use COM+ to scale well. The Business Logic Layer had two sub-layers. The custom data objects for the DAL are the first layer and are there purely for data access. Each data object represents a row in a single table (they use data transfer object pattern for remoting to the DAL). The upper layer in the BLL are the domain entities that aggregate multiple data entities and handle the relationships between them (one to many, many to one, etc). The domain entities also have type-safe collections that use the observer pattern to enforce relational integrity between the data objects. Our workflow layer can then use the domain entities from the BLL to perform the tasks the users want. I have found that this system works well and allows us to use CodeSmith to auto-generate most of the BLL objects directly from the database. It also pushes all the ADO stuff back into the DAL which is useful when you have to support (potentially) any type of database. This is also why we use our domain objects to enforce referential integrity. The downside of this system is that because ADO is remote, transactions are tricky to implement. Currently re don't have read transactions and we fake write transactions by creating a collection of data entities to be written out together (they share a base class) and writing this collection to the DAL which uses a transaction internally. Frankly, our software doesn't do anything clever with the database (it was designed in 1995 by (IHMO) a bunch of amateurs). I never had any formal education on n-tier design either, but I'm a compulsive textbook reader and my design seems to square-up well to those I have read since. PS: I am currently doing research for an article (or pssibly a series) comparing some of the ORM/persistence libraries out there. Most so far simply seem to generate wrappers for ADO datasets, but I've just started on NHibernate which seems to be more substantial. Dr Herbie Remember, half the people out there have below average IQs.
-
Well, if you consider a 2-tier application... :-D I try to (in most cases) separate out the GUI from the business logic. One app in particular used a homegrown XML scheme to do that. Sorry, it wasn't MyXAML - it didn't exist yet, and C# itself was just in its infancy. But the concepts were somewhat similar. The business rules themselves were also in a separate scripting language, the code was really just the engine that processed those rules. It made for a highly customizable application - we reused this for several products and customers, most of which needed customizations. The generation of random numbers is too important to be left to chance.
Navin wrote: The business rules themselves were also in a separate scripting language, the code was really just the engine that processed those rules That's what I've been doing! :-D Navin wrote: It made for a highly customizable application - we reused this for several products and customers, most of which needed customizations. Exactly! Marc MyXaml Advanced Unit Testing YAPO
-
So I have a question. We all know about 3-tier or n-tier development, and how great it is to separate the presentation layer from the business layer and the data access layer. My question is, how have you gone about doing that separation? No, this isn't a "how do you do it?", it's a "from projects you've worked on, how well have you achieved that separation?" and "what specific technique did you employee?" question. There's lots of ways to create this separation--messaging, mediator objects (among other design patterns), interfaces, etc. What techniques do you like? What works for you? What compromises do you make? The reason I'm asking is because I have my own techniques but I've never had any formal education in this area (or any area, for that matter). I'm curious what they are teaching people. Or is this just cultural wisdom that gets somehow transmitted to the next generation? I'm also asking because I went to bed last night realizing that the issues with n-tier development apply also to declarative programming. I woke up even more strongly convinced of this. More on this later. (And yes, I've read the Microsoft articles on tiered development, etc. Theory is great). Marc MyXaml Advanced Unit Testing YAPO
Since I am so lazy I have always, since my VB COM days, relied on the CSLA[^] taught by Rockford Lhotka. Perhaps you've read about it, or perhaps not, since some C people, I'm not saying you, would rather be stranded on a desert island than read the writings of a vb programmer. good luck, oh, and by the way and way off topic, when do you plan on releasing the algorithm? Will there be an article with it? :->, or am I pushing my luck :-D
-
So I have a question. We all know about 3-tier or n-tier development, and how great it is to separate the presentation layer from the business layer and the data access layer. My question is, how have you gone about doing that separation? No, this isn't a "how do you do it?", it's a "from projects you've worked on, how well have you achieved that separation?" and "what specific technique did you employee?" question. There's lots of ways to create this separation--messaging, mediator objects (among other design patterns), interfaces, etc. What techniques do you like? What works for you? What compromises do you make? The reason I'm asking is because I have my own techniques but I've never had any formal education in this area (or any area, for that matter). I'm curious what they are teaching people. Or is this just cultural wisdom that gets somehow transmitted to the next generation? I'm also asking because I went to bed last night realizing that the issues with n-tier development apply also to declarative programming. I woke up even more strongly convinced of this. More on this later. (And yes, I've read the Microsoft articles on tiered development, etc. Theory is great). Marc MyXaml Advanced Unit Testing YAPO
I know n-tier development is difficult, I was looking for a good solution myself a while ago. When I started studying computer science here at saxion highschool in Holland, they learned me that separation was rather simple to achieve and use. First make something standard for the data-access, a class or a set of classes that can execute queries on the database in a generic way. This greatly helps when building the business model. Next, define and build a business model. I think doing a good information analysis using NIAM or something like that can help you greatly in defining your business logic. After that you create class diagrams and sequence diagrams. If you done it right, you now will have a business model without any information about the presentation layer or anything. After you finished the business model, you can then choose your presentation layer and start building it around the model. This way it's possible to build a single model and provide a web interface or a windows forms interface for it. I think webservices are great when your thinking of attaching both to your model :) A good thing to keep in mind is: Layers may drill down into a lower layer, but never build up into a higher layer. I usually use a mix of custom classes and datasets in my business logic, since objects are easier to work with when processing information inside the business logic, while datasets are easier to use in the presentation layer for both web and windows forms. (Yes, i sneaked in some of the presentation, but this is the kind of stuff that is rather common in .NET) It's really a matter of taste when it comes to solving the problems of n-tier development. I for example created my own data-access layer classes in such a way, that I can scale my application from ms access to ms sql with just a simple configuration change. I did the same for authentication and authorisation, I can use XML, ms access, ms sql and windows server for my security information. In my opinion, n-tier development will always remain difficult, no matter if you are educated in it, or you learned it yourself by building software. The problem is the amount of work you need to put into it and that will never change :cool: Except if you use generators, but those are quite messy and too standard, I love little suprises in my programs like putting in maps with the actual occupation of seats and stuff like that. You can never do that with generated apps. WM.
What about weapons of mass-construction? -
Thanks for the response! So, if I understand this architecture, the specific UI implementations all access the business layer through interfaces, and the business layer access the data layer through interfaces as well? For example, if you have a Customer GUI (name, address, etc), when the user clicks on "OK" after, say, updating the address, does the GUI update the Data.Customer fields directly in the event handler, or does it call the business layer through something like IBusinessLayer.UpdateCustomer(name, address...), which in turn might do something like Data.Customer.Update()? I hope that question makes sense. :) Marc MyXaml Advanced Unit Testing YAPO
I think you're on the right track. As it so happens we just had a discussion along these lines. Data Objects, generally, have all methods (Update, Insert, Delete, etc) and no properties, while Business Objects have all properties (FirstName, LastName, Address, etc) and no methods. So a UI may get a business object through a call to a business layer, or data layer and any updates of the business object are passed to the appropriate data object.
-
Thanks for the response! So, if I understand this architecture, the specific UI implementations all access the business layer through interfaces, and the business layer access the data layer through interfaces as well? For example, if you have a Customer GUI (name, address, etc), when the user clicks on "OK" after, say, updating the address, does the GUI update the Data.Customer fields directly in the event handler, or does it call the business layer through something like IBusinessLayer.UpdateCustomer(name, address...), which in turn might do something like Data.Customer.Update()? I hope that question makes sense. :) Marc MyXaml Advanced Unit Testing YAPO
Marc Clifton wrote: So, if I understand this architecture, the specific UI implementations all access the business layer through interfaces, and the business layer access the data layer through interfaces as well? Actually, I don't have the need for several implementations of the business layer, so the UI implementations access directly the BL classes. The BL access the data layer through interfaces (actually, through singletons). Marc Clifton wrote: For example, if you have a Customer GUI (name, address, etc), when the user clicks on "OK" after, say, updating the address, does the GUI update the Data.Customer fields directly in the event handler, or does it call the business layer through something like IBusinessLayer.UpdateCustomer(name, address...), which in turn might do something like Data.Customer.Update()? Almost this. The GUI calls the Business Layer Customer object. Actually, there's no reference to the data layer in any interface. So, the UI calls BusinessLayer.Customer.Update(...), which in turn might do something like Data.Customer.Update(). Why go through this overhead, and not call the data layer directly from the GUI, even for the simplest things? The answer is that things are rarely that simple: any application for big companies deals with sensitive data. I believe that any piece of data should have its access controlled (think about a file system). So, even the simplest combo box that needs to call, e.g., Data.User.ListAll() needs to pass through security and access checks before the data is returned, and often those security and access checks are driven by business rule. I see dead pixels Yes, even I am blogging now!
-
So I have a question. We all know about 3-tier or n-tier development, and how great it is to separate the presentation layer from the business layer and the data access layer. My question is, how have you gone about doing that separation? No, this isn't a "how do you do it?", it's a "from projects you've worked on, how well have you achieved that separation?" and "what specific technique did you employee?" question. There's lots of ways to create this separation--messaging, mediator objects (among other design patterns), interfaces, etc. What techniques do you like? What works for you? What compromises do you make? The reason I'm asking is because I have my own techniques but I've never had any formal education in this area (or any area, for that matter). I'm curious what they are teaching people. Or is this just cultural wisdom that gets somehow transmitted to the next generation? I'm also asking because I went to bed last night realizing that the issues with n-tier development apply also to declarative programming. I woke up even more strongly convinced of this. More on this later. (And yes, I've read the Microsoft articles on tiered development, etc. Theory is great). Marc MyXaml Advanced Unit Testing YAPO
In my latest project, I got a chance to rewrite an ASP.NET app I had done rather quickly, with all of the server-side logic in code-behind files. I created a brand new project using the "Visual C# Distributed Application" template (Other Projects/Enterprise Template Projects). The result: a solution containing six projects! (whereas before it was only two). It proved to be a challenge figuring out how to split the code among the layers, and at times I wondered if the extra complexity was really worth it, from a maintenance stand-point. But it's really more how you look at it. If you see it as a whole, and the fact that debugging a specific piece of functionality can take you through several layers of method calls, then it's not as nice as having all the logic in one place. But when you look at the individual layers by themselves, it's nice to see the code properly organized and modularized so that things can be easier to find -- hence making maintenance easier. Here's how I ended up organizing the various projects in the solution: Company: - Company-wide set of utility classes. Common: - Solution-specific utility and exceptions classes. - All typed datasets. DataAccess: - Component classes that hold DataAdapter objects used to read/write the database. Data is transferred via typed datasets. BusinessRules: - Entity-based classes (Customer, Order, etc.) containing static methods that use the DataAccess classes to read/write the database. Before the data is written, the methods validate it based on the rules set up by the business. BusinessFacade: - Entity-based classes (Customers, Orders, etc.) that act as middle men between the presentation and the business rules layers, and provide caching and optimization of the data. These are stateful classes, where for example, an instance of Customers usually holds all the customers in the database cached via a typed dataset object. Web: This is the ASP.NET layer where each page typically instanciates a class from the BusinessFacade to obtain and write back the data. That's how I structured it, but I've always wondered if there's a more appropriate way. If anyone wants to critique this, please do. Regards, Alvaro
Victory means exit strategy, and it's important for the President to explain to us what the exit strategy is. -- GWB, 1999.