Some basic concepts are not completely clear for Me ( MVVM , N-layer , N-tier architecture , MVC , MVP , BLL Layer , DAL layer , Web services ..)

Question

Sorry, but I have some confusion between :

MVVM , N-layer , N-tier architecture , MVC , MVP ?

and the exactly difference between : business layer and logic layer ?

DAL layer (Data Access Layer), BLL Layer (Business Logic Layer) ?

Web services , WCF Services , Web API , Remoting service ?

Answer 1

The common theme between all of your topics is separation of responsibilities.

For example, MVVM, MVC & MVP all provide a way to architect your app so that you split your presentation layer logic from your business logic.

N-layer & n-tier is a big topic that concerns itself with how layers are defined in an app, whether they're logically or physically separated, and how & if the layers should communicate with each other. Here's a good overview: https://learn.microsoft.com/en-us/azure/architecture/guide/architecture-styles/n-tier

Business & logic layers are only semantically different from what I'm aware (although there may be some nuance that I've missed.)

A data access layer is, as the name suggests, where you access data from. For example, you could be storing data to disk, to a SQL Server database (accessed with Entity Framework), from a MongoDB instance, from a Redis cache, etc. The presentation layer of your application shouldn't care whatsoever about where the data comes from and any database calls, or file access should be isolated within a data access layer. This makes it much easier to migrate to different data access solutions in future, limits the sorts of issues that can occur in your presentation layer, and generally lets the presentation layer care about only the things it needs to care about (design-wise).

The business layer is where you may take an internal representation of your data and transform & constrain it to meet business rules. Sometimes the raw format returned from your DAL is sufficient but if you want to, for example, apply permissions or translate data-specific inferences and turn them into a domain model - this is where you can do it.

Web services, WCF, Web API & .NET Remoting are relating to networking. "Web services" is just services that are delivered over the web, so for example rather than having one big monolith application, you could split your application up into separate web applications that all communicate over HTTP(S). WCF is an implementation of this concept where you send messages to an endpoint (typically with a SOAP/XML encoded request message), then the service can send you back a message and service reference created by the the WCF framework deserialises the message into an object and as a service consumer you may be unware that you're communicating with another machine.)
https://learn.microsoft.com/en-us/dotnet/framework/wcf/whats-wcf

(ASP.NET) Web API is another implementation of a web service technology, which is a bit more modern and integrates more frictionless-ly with service consumers that aren't also using .NET. Practically this means that it can produce/consume JSON more readily than WCF. It's also a more lightweight abstraction over HTTP and (in my opinion) that makes it easier to reason about.
https://learn.microsoft.com/en-us/aspnet/core/tutorials/first-web-api?view=aspnetcore-6.0&tabs=visual-studio

As for Remoting (assuming you mean .NET Remoting) I haven't seen many instances of it still in use out in the wild, but it's quite old now & has been superseded by WCF. It was just another method of sending/receiving messages between either different machines on a network, or different processes on a machine.