0

myoverall question is trying to understand what is the best practice of building a large .net core API.

Atm, Iv'e been taught to work with 4 different layers -

  1. API (controllers)

  2. Entity (just simple classes without any implementation, includes database entities and custom classes for user requests/response)

  3. Logic (Basically built the same as the entity, but instead of classes it has the actual logic of each class)

  4. Data (does the actual talk with the database so I can implement different db's behind it)

I currently seeing a video guide of State design pattern and it seems like he combined the entity and the logic layers, as he has the actual logic implementation on the classes themselves. Is that the right way to work?

The way I do it is that the API layer creates an instance of the logic layer and sent the requested entity to the logic where the actual code happens.

Second question - I am building an app that does bank transactions, is it correct to have a property on the transaction class that is called State, and the type is Interface TransactionState

and have lets say 3 state classes that inherit from TransactionState interface?

and than the actual logic I should do from the class state? (Which brings me back to the first question)

for example - 

Transaction  newTransaction = new Transaction(.....)
newTransaction.State.Validate();
newTransaction.State.Proccess();

sorry for the long question, hope someone will have the time to read it lol

Thanks !

sajadre
  • 1,141
  • 2
  • 15
  • 30
Ben
  • 793
  • 2
  • 13
  • 29
  • 5
    Best practice for *what*? A pattern is "a solution to a problem in a context". That means each pattern solves a *problem* but only in a *specific* situation, ie context. You don't pick them because they are good, you use them because you want to solve a specific problem and have a specific set of restrictions and requirements, ie a context – Panagiotis Kanavos May 10 '19 at 07:59
  • Hi, @Ben, Stack Overflow is a site for helping with concrete programming problems, so your question is not a good fit. Maybe ask it on one of the other Stack Exchange sites, like the software engineering one? – Frauke May 10 '19 at 08:01
  • 1
    The thing to keep in mind with "examples" and "videos" is that they're trying to keep things as simple as possible to explain what they're doing.. I wouldnt take a video as an example of best practise, unless that is specifically the purpose of the video. Normally, the more broken down and seperated your code is, the easier it tends to be unit test – Robert Perry May 10 '19 at 08:01
  • From what you've described above (the fours layers), you're using an N-tier architecture. There's nothing wrong with using this architecture at all, in fact it's a really good architecture for separating parts of your application out. As @PanagiotisKanavos has said, though, there's no one design pattern to rule them all. Each pattern is suited to a different situation, and you need to think about the application design that you're working on and tailor your choice of pattern (or no pattern at all, which is just as valid) it to suit that. – Jamie Taylor May 10 '19 at 08:02
  • 1
    Here's part I) https://stackoverflow.com/questions/23648832/viewmodels-in-mvc-mvvm-separation-of-layers-best-practices – Stefan May 10 '19 at 08:03
  • I use a simple rule of thumb, if you have to ask, you haven't done it enough. There is never one way to create something as integrate as an API. I would recommend just programming and figuring out what works and what doesn't. Most of my libraries are build on the "If I was someone else using this API would I enjoy using it" for the interface and the "If I had to change that and that, would my design keep up" for the actual separation of concerns and design practices internally. – Lloyd May 10 '19 at 08:06
  • Please do not use the name `State` for anything. You may as well name it `Variable`. It means something specific to *you*, *right now*, because you're working on a specific problem. To someone learning your code, it is utterly meaningless. – John Wu May 10 '19 at 08:42
  • @JohnWu Good comment, I'll name it TransactionState. ty Thanks for the comments guys, the question was referring to best practice for writing code using design pattern, Im aware there are multiple design patterns out there :) – Ben May 10 '19 at 08:46
  • Honestly Ben that is even worse. They already know its a property of a transaction because of its location in the object model. What does it actually *mean*? – John Wu May 10 '19 at 08:47
  • @JohnWu The state of the transaction lol, lets say I have 4 concrete classes - TransactionNotValid, TransactionValid, TransactionSuccesful, TransactionFailed – Ben May 10 '19 at 08:48
  • What you are describing sounds like the transaction's status with respect to a posting process, so perhaps `PostingStatus`. There could certainly be other forms of state required as your system grows, e.g. replication state, lock state, booking status, approval workflow step, etc. Five years from now, engineers will look at the name of your `State ` property and wonder what the heck you were thinking. – John Wu May 10 '19 at 09:48
  • design patterns and best practices are reusable solutions that prevent you from repeating your code there is not any relationship between using API or etc. – sajadre May 10 '19 at 11:51

0 Answers0