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.
Related
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.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 8 years ago.
Improve this question
I am trying to grasp the important concepts of Onion Architecture and had a question I was asking myself after reading an article. Look at the Domain in the architecture showed in this image: http://tonysneed.files.wordpress.com/2011/10/onion-proj.jpg?w=282&h=494
What is the practicality of separating the Domain.Entities and Domain.Interfaces in two separate projects instead of having one Domain project with a entities and Interfaces folder? I am not very experienced but I don't see a scenario where one would thank god he has the domain entities and the domain interfaces separated..
How about so that the interface definitions can be published to clients, as open-source, while the implementation remains proprietary. Just for one of many reasons why this is desirable.
Three very good reasons which are already covered in the article from which you got the image link:
Testability. Unit test data context operations within that context.
Maintainability. Maintain business logic without affecting data access logic and vis-a-versa.
Longevity. ORM technologies improve or die (ala Linq-to-SQL), you are free to swap out your entire datacontext for a new one without wreaking havoc on your business logic.
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
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.
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 am creating a asp.net mvc2 project which contains multiple modules in the project.I am thinking to create supprate controller for each module, but i want to know what are the advantages & disadvantages out of it?
Seperate controllers means a Seperation of Concerns, you would have separate controllers to handle logic that should be separated. So you won't get a cluttered controller handling everything in your application. Besides clarity in your application, this brings the benefit that if you need to change one thing, you don't break other code handling other logic in the same place.
Naturally this separation is also present in your Views folder, so you'd have clear oversight what's going on where in your app.
Also, if you have a lot of dependencies that your one controller needs (like services getting different domain models) you would have these listed in one place, which would make it less clear what the primarily function of that controller is. It's nicer to have more controllers with less dependencies each.
Another benefit is that you get user friendly Urls without much effort:
www.domain.com\home\index
Pretty much spells out this is the homepage.
And:
www.domain.com\account\login
does so too.
Basically, make objects (controllers) for each "section" of your web app, like you would make objects for each functionality of the business logic.
i would read this article: Biggest advantage to using ASP.Net MVC vs web forms
since it already covered your question for a big part.