We Keep Coding

difference between EF and Entity-SQL when working with .net core [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
I am beginner to .net core. And I am working on an enterprise application where there are multiple classes interfaces for multiple project inside a one solution. i know Entity Framework won't be a good idea if we are facing huge number of wrappers. But indeed its giving me efficiency of coding. On the other side of it Entity SQL has its own benefits.
But still want to really understand the best practice and which one to implement when it comes to Enterprise application knowing it will have number of classes, Data filtration, Generic Types, Flexibility, performance vise when querying DB.
Looking forward to get some really helpful understanding from experts. Thanks in advance.

TL;DR;
The "best practices" depends on the use case. Its a set of tools, not a silver bullet.
Sometimes EF works for your case, sometimes not. Sometimes you want a monolith, sometimes you dont.
Try, experiment fail and succeed.
Best practices regarding to techniques are irrelevant; implementation change all the time. So;
define functional requirements
define none functional requirements
do a PoC with some relevant loads etc.
At enterprise level consider these additional properties:
security
operational functionality
cloud / none-cloud
This is the best I can do, given your question.
Explain the case and we could give some direction; but its not a template fitted for all cases.

How do you structure your business logic folders? [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
I've been reading a lot around how you guys organise your business logic, and it's evident that the view is there's no wrong implementation as long as it's decoupled from the other layers within your application.
My question relates to the physical implementation of your layer rather than conceptual. How do you prefer to actually implement the structure of your business logic layer?
I tend to have a 'services' folder which holds persistence and query service classes for each of the modules/departments of the application.
What's your preference on the folder structure of the business layer specifically, so if you were to view it from a solution explorer, what folders and sub folders do you tend/prefer to create?
Edit:
I'm asking what you prefer to label your folders as. I call my module folders 'services', I've also seen them labelled as 'EntityHelpers'.

You are asking the fundamental question of architecture: "I have a lot of logic...how do I structure it?" It is hard to answer such a general question in brief since numerous books have written about various aspects of this problem
The fundamental design principles: Layering, slicing, separation of concerns, single-responsibility, high-cohesion-low-coupling and so on should be applied at all levels of the architecture, not just the top level.

A "folder" wouldn't be over simplistic to organise your solution. Although, if you are working with in a relatively small problem, it should be just enough. Thinking about layering and keep your business logic tight and coerent, I would suggest you to read more about DDD from Eric Evans.
You would create your business logic in your domain layer, decoupling it from view(not necessarily web), application and infrastructure logic.
Check out the Microsoft example, it captures the essence of DDD.
There is also the Vaughn Vernon DDD book, who gives am practical approach to understand it use.

Proper namespace naming for new sub-business unit [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
We have the current structure:
BusinessName.Common - common entities, classes, utilities
BusinessName.Services - business services
We're adding a sub-unit called "Medical", of which it will contain a similar structure. I'm stuck deciding on the best naming convention.
Option 1
BusinessName.Medical.Common
BusinessName.Medical.Services
Option 2:
BusinessName.Common.Medical
BusinessName.Services.Medical
There will eventually be more sub-units such as this.

I would stick with Option 1, because each domain should mimic the same child namespace naming scheme.
If you call BusinessName.Common a shared library across all domains (what you call units...), a specific domain common members are of the whole domain, thus, your naming scheme should be BusinessName.[DomainName].Common, BusinessName.[DomainName].Services.
Anyway, let me add more value to this answer. You said that Common project/namespace would contain common entities, classes, utilities. I'm not agree with this. A common library should be a cross-layer library (vertical). My advise is that you should organize your solution this way:
BusinessName.Common: Infrastructure code. Any domain-related code shouldn't be here. Classes, interfaces and enumerations here should be usable from any layer and tier.
BusinessName.Domain: Common domain entities and services. I would put here common domain interfaces, abstract classes, base classes...
BusinessName.Domain.[SomeDomain]. For example BusinessName.Domain.Medical. I would put here everything about domain. In a specific domain there're no common entities to any other domain, because this would defeat the purpose of organizing your project in domains.
In my own projects I prefer to use Shared identifier instead of Common, but this is just my opinion.

Are there times when combining business logic and data structures is a good idea? [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I've recently been told that if programming a data structure that--for the time being--will only need one type of business logic, I should build all the logic directly into the class and only worry about moving it into a separate class when the structure needs different logic.
My question is: Is this good practice, or is it better to separate the logic and structure from the beginning if there is a reasonable potential that the business logic will change?
My gut instinct is to keep the logic separate, as that seems to follow the open/closed principle, and combining structure and logic seems to violate SRP.

This is a pretty subjective question and essentially strikes at the heart of object-oriented programming, in which combining data and logic is the norm. I generally prefer to keep the data structure separate from associated logic if the data structure is used for communication with another system (essentially following an Interface Definition Language approach), or if there are cases where the logic is specific to a very specific context.
In cases like lists, queues and dictionaries in object-oriented languages, the data and logic combine to form a cohesive object, and are mutually dependent. In those cases, separating the logic and the data would not really make sense in an object-oriented language like C#.
However, in other, specific cases, it would make sense to separate the data and logic. For example, if you're creating an Invoice object, and it needs to be processed by any number of downstream systems, then you don't want to put the logic for those downstream systems in your Invoice. Instead, that logic should be separated out.
So, I guess the short answer is: It really depends on what you're doing.
Hope this helps,
Nate

Confusion between OOP approaches among different developers [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I have been developing web apps using .net and c# from last 1 year, but there is some confusion going on in my mind regarding OOP principals implementation.
1) What i learned from the object oriented books was that every class should have its specific methods, but when i came across the code of a senior developer, i saw that the developer has created a separate business layer with a business layer class containing all the methods of all the classes.
Is this approach of using separate business class containing all the methods being used in our app is justified by any design pattern or by any other resource, or it is just an awful design?
Please elaborate your answer in detail as this can also helps other newbies out there...

Architecture is an art not a science. There are good architectures and bad architectures, but there is not a single correct architecture.
For example your Senior developer may have created a Facade (design pattern) on top of your more complicated data access layer to simplify data access. For instance you could have a dozen entities for ordering a product, and you would like to create a facade for everything you need to do while ordering a product.
Just look at the architecture and try to analyze yourself if you think it could be better. The more architecture you know the better your judgment will be, but architecture is rarely black and white.
Also, just because someone is senior it doesn't necessarily mean that they know what they are doing or that they don't make mistakes.
Also, Inheritance can be done in EF:
Inheritance in EF

there is no single architecture one can follow, for example when building strictly SOA systems it is VERY common to have model classes that are only data, no methods whatsoever. Whereas all the business logic classes exist in a different namespace. Furthermore when you send your domain classes over the wire you will typically create dedicated classes for that purpose in a different assembly dedicated to the SOA.
The architecture I describe above is directly from the Microsoft Architecture Guidance package for VS.