How do you go about creating a "logic tier" (probably in .Net)?

[DaveJ]

Last edited Wed Apr 2, 2014, 07:13 AM - Edit history (1)

I think we need a logic tier where business objects can reside, like Customers, Orders, etc, so that they do not have to be constantly reinvented every time a request comes along. I've grown fond of OOP and if it's not the correct and modern approach to coding, I'd love to be convinced to go back to the linear procedural style if that will make me fit in better. But for now it just seems like OOP is the way coding is supposed to be done, if I'm not mistaken. I'm not sure how to make people start learning OOP, but I've been given the green light and going to see what happens.

We have multiple skills sets, both open source and .Net, and I primarily use .Net and the MVC design pattern. Would creating a logic tier involve creating a project named something like "Logic Tier" and publishing it to an IIS server and exposing it in the form of WCF, for instance? I've already got a contracts.cs file with interfaces in it, and a services.cs file. I have those in one project that I'm sharing among two solutions at the moment. Should those be turned into a WCF project? I've seen very lengthy descriptions of architectures, but would like to know if this WCF approach would be a reasonable way to just get started with a basic logic tier, or if there is another way.

Also, are stored procedures considered part of the logic tier, and if not, how do you decide whether to put code in SPs vs the LT?

[paulkienitz]

1. my experience

What I've experienced is that trying to put business rules and other application logic into .Net classes doesn't work out very well -- with the best intentions, it doesn't fit smoothly and you always end up with big pieces hanging out. The business logic keeps wanting to stick closer to the database than to the .Net app. So IMO it's better to just take the approach from the beginning that most of it belongs in stored procedures, not in .Net classes.

As for a WCF interface, first ask yourself if there's a real need for splitting the app over two servers. If not, using it is probably just overengineering, and adding an unnecessary additional source of potential problems. Don't worry too much about the risk of discovering later that you wanted it after all -- splitting an assembly off into a service isn't a big deal, should it become necessary. So I'd say don't be premature about it.

[DaveJ]

2. What about the common knowledge not to put business logic in SPs?

I've 'surveyed' the programming community (Google searched) and there seems to be a great consensus that stored procedures in an inappropriate place for business logic. I feel like it's 1999 when I'm doing that much coding in T-Sql. It's so easy to make a mistake that gets buried, there's no connection to the real world logic like there is with actual OOP objects, and for seemingly every function requires a new SP to be written, whereas with an OOP object, it can just be extended, or new objects can be added until you eventually have a machine that fits together perfectly running like a Ferrari.

[paulkienitz]

3. We would all PREFER not to put it in stored procs...

but from what I've seen, this "common knowledge" often ends up just being common wishful thinking.

[DaveJ]

4. How about video games?

I'm very impressed by video games and the way they leverage OOP. Not to say that OOP is exclusive to games, but they are proof of how it's used on a routine bases. Like Grand Theft Auto V for instance, a gigantic expansive city in amazing detail, is something that could only have been accomplished with objects. With every revision their world becomes larger and more refined. If the project needs to be bigger, they just hire more programmers, and it just works. Otherwise I think hiring a bigger team would just be useless because each member would have to learn the sequential logic of the code.

Actually I find it extremely easier to create objects rather than trying to trace through SQL, or any other language, line by line. I did program procedurally for most my life and only began to get the hang of OOP recently. I certainly can't make other people gain an appreciation for it, or in some cases even try, and if nobody else does it then yeah it's kind of like you said wishful thinking.

Anyway I'm going to create a project now based on objects and if I'm the only one using it then fine.

[paulkienitz]

5. video games are a perfect use of OOP

In a video game, most of what's going on is a complex real-time simulation. OOP makes perfect sense for that purpose. The active simulation is central, and any database activity is a secondary consideration. But in business applications, the real-time activity is of minimal importance, and the database content is all that really matters. For that kind of situation, manipulating your data in .Net OOP objects can easily become, in terms of practical results, nothing but an inefficient and unreliable means of implementing stored procedures.

Maybe someday we'll have OO classes which really integrate well with a database so that coding with them is a better alternative than a SQL procedure is. As far as I've seen that day isn't here.

In every large business app I've worked on, we've had a layer of OOP business objects, and mostly they've ended up being just thin wrapper layers around logic implemented inside the database. If they didn't start out that way, they soon evolved in that direction.

[ChromeFoundry]

6. Have you looked into the LINQ-to-Relational Data?

Since you are developing in .Net and most likely a SQL Server backend, you should really look into LINQ-to-SQL and LINQ-to-EF (Entity Framework). If you are looking for a way to encapsulate business logic in one layer and data access in another, you could easily implement this in either a single or multiple assemblies. The number of tiers you implement all depends on the complexity of your needs.

This link provides a good overview:
http://msdn.microsoft.com/en-us/library/cc161164.aspx

Exposing your data through WCF makes sense if your need to consume the data from multiple clients or applications. WCF makes it very easy to build up your data contracts and manage data from typical clients via REST, SOAP, JSON, etc.. and it is very easy to build it as a self-hosted Windows Service, no need to be hosted by IIS.

[DaveJ]

7. I've been doing the first thing for quite a while

I've been using edmx and Linq to Sql. Now basically I just want to create objects that represent the needs of the organization. So today I just created a project that each solution I create shares, containing business objects (orders, customers, etc) interfaces and classes. When an object is updated in one, all the other solutions must play along.

What I'm wondering is, is what I've done considered a rudimentary tier? just placing those objects into a shared project and naming it Logic Layer?

I use MVC but I am no really a network architect.

Later on, if anyone else is interested in using those objects, I can share them using WCF.

Thanks for articulating what's happening, I have trouble doing that myself.