[RESOLVED] N-Tier / SOA questions

I'm creating an N-Tier (or at least I think its N-Tier!) solution where I have the following:

WPF client side application (presentation layer)
WCF service hosted in a windows service (data access layer)
SQL database (data layer)

Now bearing in mind this is the first time I've tried to design anything like this, I might be going about it completely the wrong way...
I've created 3 examples classes that would be my 'business objects' (im not quite sure where that fits in within the layers I listed above, because these business objects would be defined in a DLL that would be used by both the presentation layer and the data access layer). You can see them here:

http://i135.photobucket.com/albums/q.../BOClasses.jpg

So then in my WCF service (data access layer) I would have methods like this that would be exposed to the WPF client:

http://i135.photobucket.com/albums/q...AL-Methods.jpg

These are just examples but you get the idea. Is this the right way to do something like this?
I saw one design that someone had posted somewhere that basically looked to me like it merged the Business Objects and the DAL together because in their class that represented an order, they had properties like you would expect for Order Number etc etc but then they also had methods like "GetOrders" within there too.
I dunno I'm still very new to this type of design but I thought that the idea of the business objects was that they just represented business items, such as orders etc, so I thought they would just purely hold properties/fields and no methods or anything like that.

Just wanted your thoughts and suggestions on whether im on the right track or not :)

Thanks
Chris

Also, here's a quick diagram I made of my solution, does this look right for an N-tier architecture?

http://i135.photobucket.com/albums/q...tionDesign.jpg

There are various ways that you can break up responsibility into layers and a lot of people do combine multiple responsibilities into a single layer. I wouldn't call myself a complete expert but here's how I would recommend you go about this for optimum separation of concerns and, very importantly, testability.

1. Your database is the data layer.

2. Define an entity layer that contains all your business objects and only your business objects. You might generate these entities using the Entity Framework, LINQ to SQL, some third-party tool or you might write them yourself. If you do use a tool then your entity layer may also include a container class that acts as a context through which to access the entities. This is certainly true of the Entity Framework and LINQ to SQL.

3. Define a repository layer that performs the data access. It might contain LINQ to SQL or LINQ to Entities statements that act on a data context, or it might contain inline SQL statements that you've written yourself, or it might contain references to stored procedures contained in the database. Just be aware that, while there are various advantages to using stored procedures, doing so often entails pushing some of your business logic into the data layer.

4. Define a service layer that invokes the repository layer and implements all your business logic, including validation. This service layer could be incorporated into your WCF web service but I'd recommend not. That way you can test your business logic without having to make web service calls and you could also remove the web service from the equation and the application would still work.

5. Define a transport layer consisting of your WCF web service.

6. Define your one or more presentation layers.

Also, make sure that any types that are defined in one layer and used in another actually have their functionality defined in an interface and there implementation provided in a class. That removes each layers specific dependencies on other layers so you can remove or change one layer with essentially no impact on the others. It also makes testing layers in isolation possible, because you can create a mock or fake implementation of, say, your repository layer to be used in testing your service layer. That would mean you can test the service layer without actually having to access the database, which is too slow for unit testing.

The exception to the previous rule would be your entity classes, which generally wouldn't implement a specific interface.

Thanks for that, see my comments below :)

Quote:

---

1. Your database is the data layer.

---

Yep, cant argue with that :)

Quote:

---

2. Define an entity layer that contains all your business objects and only your business objects. You might generate these entities using the Entity Framework, LINQ to SQL, some third-party tool or you might write them yourself. If you do use a tool then your entity layer may also include a container class that acts as a context through which to access the entities. This is certainly true of the Entity Framework and LINQ to SQL.

---

I'm planning to create the business objects myself as I showed in the example screenshots, but when you speak of this 'entity layer' what exactly is it that you mean? I mean, do you just mean for example that the DLL that contains these business objects would be my entity layer?

Quote:

---

3. Define a repository layer that performs the data access. It might contain LINQ to SQL or LINQ to Entities statements that act on a data context, or it might contain inline SQL statements that you've written yourself, or it might contain references to stored procedures contained in the database. Just be aware that, while there are various advantages to using stored procedures, doing so often entails pushing some of your business logic into the data layer.

---

So this sounds like my data access layer but with a different name, which I'm planning to make with inline SQL statements that are in my WCF service (exposed as the methods you see in the screenshot in my first post)

Quote:

---

4. Define a service layer that invokes the repository layer and implements all your business logic, including validation. This service layer could be incorporated into your WCF web service but I'd recommend not. That way you can test your business logic without having to make web service calls and you could also remove the web service from the equation and the application would still work.

5. Define a transport layer consisting of your WCF web service.

---

This is the bit that confuses me - I dont see where this 'service layer' comes into it. I mean if my WCF service has the methods in it that perform the data access and then it just passes the results back to the presentation layer then where does the business logic fit into that? More to the point, what exactly is the business logic? Could you give me an example in my scenario what sort of thing this would contain? My application is for logging jobs that our IT department has to do, so it basically just displays a list of jobs and allows the user to view/update various parts of the job such as the related End User, the Admin User its assigned to, and they can also update it with work they have done on each job. Obviously there's a lot more to it than that but thats the basic idea. I just dont see where the 'logic' comes into it - the user clicks a button and it allows them to type in some text that gets stored with the job, or it allows them to select something from a drop down list etc, where's the business logic in that? Maybe I'm looking at it the wrong way, is business logic more of a high level thing and not actually methods and properties in code etc?

Quote:

---

6. Define your one or more presentation layers.

---

I can handle that one :)

Thanks again

Yeah, the entity layer is just a DLL that contains your business entity classes. I would suggest using something like the Entity Framework to generate your entity classes. There really is no point spending lots of time doing that sort of grunt work when the point of the app is not the entities but how you use them.

Yes, the repository handles the data access so it is basically the DAL. Again, if you use a tool like the Entity Framework then you can use LINQ instead of SQL to retrieve data. Much nicer, let me assure you.

It sounds like you're talking about combining all the business logic and data access into the WCF web service. You can certainly do that if you want but what if at some point it's decided not to use WCF anymore? You'll have to trash all you data access and business logic along with the WCF. If you create separate repository and service layers then, if you remove WCF, those other two layers stay unchanged and you can simply slot in another intermediary between your presentation layer and your service layer.

Business logic is any processing you perform on your business entities that is specifically presentation or access. For instance, if the user entered a name for a new record and you had to make sure that that name didn't already exist, doing that is business logic. Sure, the data access layer has to actually get the data but it's dumb in so far as it has no idea what it's getting the data for. It's the business logic that knows how to use the data.

Also, as I said earlier, separating your layers more completely enhances the testability of your code, and that's no small thing.

Ah I think I see what you mean :) I'm just reading this as well which is helping me get to grips with it: http://www.codeproject.com/KB/archit...nessLogic.aspx
and this which is helping with the whole service side of things: http://www.15seconds.com/issue/031215.htm

The business logic layer again though can just be a DLL containing classes/methods cant it?
So for example my WCF service will be using the data access layer methods (referenced from their own DLL) to get data from the database and then using the business logic layer methods (again used from its own DLL) to actually decide what to do with that data, then it will be returning the result (via the transport layer) to the presentation layer to be displayed or to inform the user that whatever update/delete they performed was successful. Thats about right isnt it?
If thats the case then one thing im not sure of is where the data is actually put into the business objects. I mean does the data access layer return data from the database in a raw format and then its the business layer that puts the values from the database into the relevant properties of the business objects, or does the data access layer do that and then just pass the populated business objects to the business logic layer? (hope that makes sense)

OK the more I look into this the more I confuse myself lol just when I think I understand it, I run through an example scenario in my head and something just doesnt fit.

So, I've started to create the necessary projects in VS just to help me see exactly what I need and what goes where. This is my solution at the moment (pretending my app is named App1):

Solution - App1
==Project - App1BL (business logic)
==Project - App1BO (business objects used by the client and the business logic)
==Project - App1Client (WPF desktop client application)
==Project - App1Server (WCF service that uses the DAL, BO and BL to provide data to respond to client requests with)
==Project - App1ServerService (Windows service that just hosts the WCF service)
==Project - App1DAL (data access layer, accesses the SQL database)


So although I have all these different 'layers' most of the work will actually be done in the WCF service but it will just be using the methods from these layers to do its work. Is that the right kind of approach?

Also, the client is going to have to have some business logic in it to prevent unnecessary calls to the WCF service across the network isnt it? Otherwise I can see the whole thing getting very slow if the client application has to keep waiting for responses from the service for pretty much every button click.

EDIT: for anyone else looking at the same kind of thing, I found this diagram which is a nice simple demonstration of what exactly the business logic is: http://upload.wikimedia.org/wikipedi...torVersion.svg

No, the web service should do very little work. All it should do is make calls to your service layer. It's the service layer that does the work. You might also want to add an extra service layer on the client side, between the UI and the web service. That way you can perform validation before invoking the web service instead of after.

You fire up an application, i.e. a presentation layer. It might be a WPF app, an ASP.NET app or whatever. The presentation layer makes requests for business logic services from your client-side service layer. Examples may be to list all the Thing entities or to save a new Thing entity. The client-side service layer performs any validation required, like ensuring that all required fields have been populated in a new Thing. The service layer can then reject the request and notify the presentation layer of the problem, or it can can invoke the web service and either pass data to it, request data from it or both. The web service then simply passes the request on to the server-side service layer. The server-side service layer will also apply any business logic required to the request, like validation. If the request is valid it will then invoke the data access layer, which will then either save data to the data layer, get data from the data layer or both. The server-side service layer will then apply any required transformation to the retrieved data and pass it back to the web service, which passes it back to the client-side service layer, which transforms it as required and passes it back to the presentation layer, which displays it to the user.

Now, in that scenario there is some redundancy with the client-side and server-side service layers. As such you might choose to omit either of them but the advantage of having the two is it modularises your application to the degree where you could remove everything from the web service up and replace it with a simple presentation layer and it would all still work. Likewise you could remove everything from the web service down and replace it with a simple data source and it would all still work. The point of this modularisatin is NOT to make your app work better as is, but rather to make it more testable and to make it more robust in the face of change.

So, the presentation layer is responsible presentation only. It doesn't know what the data means or where it comes from, only how to display it. The repository layer is responsible for data access only. It doesn't know what the data means or where it goes, only how to retrieve and save it. It's the service layer where all the intelligence resides. The service layer knows what the data means, how it should look and how it will be used. That intelligence is your business logic. It includes things like validation and transformation. In your case the web service would be dumb too. It is responsible ONLY for passing requests from the client-side to the server side.

One final point to note is that multiple layers will need to have a reference to your entity layer because entities are getting passed through pretty much all layers.

Yeah I understand that but when I say the WCF service is what does most of the work, I mean thats where the various methods from different 'layer' DLLs are called and used. Surely you don't mean literally having a separate service for each of these layers because then I would end up with a WPF client application on each workstation, a service running on each workstation, a WCF service on a server, a service for business logic on another or the same server, a service for the DAL on another or the same server, and then the SQL database on another or the same server.
When I talk about a service I'm talking about a windows service (as in the ones you see in the Services MMC snap in).
I assume when you talk about a service layer you just mean a DLL? This is the thing I think I'm struggling to grasp - what exactly a layer is.
For example, lets look at your client-side service layer that you mentioned that provides validation. If this is just a DLL that contains various functions that validate data then surely its still the presentation layer that actually calls and uses these functions? So if I have a form in my WPF application where users can create a new job, the WPF application itself would have a reference to the client-side validation service layer DLL and would have something like this (assuming my service layer DLL is called App1SL):

vb Code:

Private Sub SubmitJobBtn_Click(e, Sender) blah blah blah
   If App1SL.Jobs.ValidateNewJob(JobNametxt.Text, AssignedTotxt.Text, DueDatedtp.Value, etc etc) = False Then
        Messagebox.Show("Invalid data was entered")
   End If
End Sub

So although the actual function code is contained within a 'service layer' DLL its still the presentation layer that is executing this code, which is the same situation as the WCF service and the various layers that it would execute. This is what I meant when I said the WCF service would do a lot of the work, not that all the code would actually be written in the WCF service but that it would be the WCF service that executes the code from the various layer DLLs.
Am I still way off the mark? :)

I think you may be confusing a web service with a service layer. What I mean is:

Presentation layer on client (WPF)
Service layer on client
Transport layer on server (WCF web service)
Service layer on server
Repository layer on server (LINQ to SQL, LINQ to Entities, T-SQL, etc.)
Entity layer (LINQ to SQL, Entity Framework, NHibernate, custom classes, etc.)
Data layer on server

I haven't specified that the entity layer is on the server because all the other layers would require a reference to the entity classes.

All the smarts is in the two service layers. The only work the web service would do is passing calls from one service layer to the other. It would obviously have to pack and unpack data to be sent over the wire but that's not something you have to implement yourself. That's what WCF does for you.

N.B. There is only one instance of each server component. Every client deals with the one web service and then the layers below that are single instances too.

Yeah but can you just define what a service layer actually is? It can just be a DLL cant it that my presentation layer uses right? Like in the example code I posted in my last post. If not then how do you actually use this service layer, how do you tell this service layer to do some work if its not just a library that the presentation layer has a reference to?

Each layer is a conceptual separation of responsibility. Generally it's a good idea if the physical separation matches. Yes, the service layer would be a DLL. It would contain one or more classes that have methods to get data and save data, performing the required validation and transformation along the way.

right, that makes sense then. So the example code I posted is on the right track yeah?
and my solution structure looks like the right sort of thing?

Quote:

---

Solution - App1
==Project - App1BL (business logic)
==Project - App1BO (business objects used by the client and the business logic)
==Project - App1Client (WPF desktop client application)
==Project - App1Server (WCF service that uses the DAL, BO and BL to provide data to respond to client requests with)
==Project - App1ServerService (Windows service that just hosts the WCF service)
==Project - App1DAL (data access layer, accesses the SQL database)

---

Thanks for your patience :)


EDIT: Also, as for the physical separation, this is how I was planning to have it:
On Client Workstations
Presentation Layer
Client-side business logic/validation layer
Business Objects/Entities

On Server 1
Server-side business logic/validation service layer
Data access layer
Business Objects/Entities

On Server 2
SQL Database

Server 1 and Server 2 could be the same server if necessary

That looks like it except that your Server should not use the DAL and the BL. The Server uses the BL and the BL uses the DAL. Each layer should only know about the one below it.

Also, with regards to this:

Quote:

---

So although the actual function code is contained within a 'service layer' DLL its still the presentation layer that is executing this code

---

That's not really true. Yes, the presentation layer has a reference to the service layer and it does call methods of the service layer, but it's not "executing" those methods. If you're my boss and you ask me to do a job, I go and do it and report the result to you, did you "execute" the job? No, you just asked me to do and I did it. You made the request and made use of the result but you have no idea of what happened in between. The same goes for your code. The presentation layer asks the service layer to perfrom a task but its the service layer that performs it. The same goes for all the other interactions. The service layer asks the repository layer to get some data but the how that gets done is of no concern to the service layer. It just makes use of the result. This is all conceptual stuff but it's important to have that stuff straight so that you can create a clean implementation.

Quote:

---

Originally Posted by jmcilhinney

That looks like it except that your Server should not use the DAL and the BL. The Server uses the BL and the BL uses the DAL. Each layer should only know about the one below it.

---

Thanks, I guess I kind of knew that but seeing it written down helps to clarify it.

Quote:

---

Originally Posted by jmcilhinney

Yes, the presentation layer has a reference to the service layer and it does call methods of the service layer, but it's not "executing" those methods.

---

Yeah I guess my terminology is just a bit wrong - I just meant that because a DLL on its own cant do anything, its the EXE file that my WPF presentation layer runs in that will actually make the DLL do something... (still a bad explanation but I do understand it now)

Quote:

---

Originally Posted by jmcilhinney

This is all conceptual stuff but it's important to have that stuff straight so that you can create a clean implementation.

---

Which is why I'm spending so much time trying to make sure I understand it before I actually start writing any more code. Speaking of which, from what I've read it seems that most people recommend starting a project like this at the data layer and working your way up, so I assume creating the necessary tables etc in the SQL database is the first thing to do? If so then I guess I need to do some more thorough planning as I currently have just a vague idea of what tables/fields I will need in the database..

You could use a bottom-up approach, which most people would do, or you could use a top-down approach, which would be favoured by those into test-driven development.

OK cool well I guess I'll try and do it the way that most people do and start from the bottom (data) and work my way up.

Thanks for your input :)

Chris

Not that I'm saying you should or shouldn't do it but TDD actually makes a lot of sense. It didn't to me at first but, especially with ASP.NET MVC lately, it actually fits really well. Separating applications into well-defined layers actually facilitates TDD. It's just not really practical otherwise.

Excuse my ignorance but what does TDD stand for?

EDIT: according to google its: A style of programming where tests for a new feature are constructed before any code is written. Code to implement the feature is then written

So I assume its Test Driven Development.

http://upload.wikimedia.org/wikipedi...evelopment.PNG

Quote:

---

Originally Posted by jmcilhinney

you could use a top-down approach, which would be favoured by those into test-driven development.

---

You decide what your app, or a component thereof, is supposed to do first and then you write a test for that. Initially the test will fail, so you then write some code to make the test pass. Once that's done you refactor the code to optimise it.

It seems odd at first but it actually makes a lot of sense, although it requires that you do things in certain ways or it just becomes impractical. For instance, as I said earlier, using interfaces to represent each layer makes your code more testable. If your repository layer implements a repository interface then you can test your service layer using a mock or fake repository that implements the same interface but doesn't actually interact with the database. This lets you isolate the functionality of the service layer from the functionality of the repository layer, so you know that any issues that arise are issues with the service layer. It reduces noise and lets you concentrate on one feature or unit of functionality at a time.

I have to admit, TDD is much easier when the tools provide refactoring support so it tends to be easier in C# than in VB and easier again with the help of ReSharper or a similar tool.