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.
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 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.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
Sorry for the noob question but I've always had a hard time distinguishing situations when it's good to create a function or a class. For some of the smaller programs I write at work, I write a whole bunch of functions to carry out specific tasks. The programs all work as intended. However, when I have some of my more senior developers take a look to give me their critique, they rewrite a lot of my functions completely over as a class. These are my coworkers so I don't want to look completely incompetent (I just started this job as a junior developer) by asking them why they did that. What do you guys think?
That is too broad question and you really have to understand the concept of the Object Oriented Programming and when you should use it.
Note: Bellow you will find my personal opinions (some of them borrowed from great books' authors and experienced programmers), and for sure the things highlighted bellow, does not reflect the entire power of the Object Oriented thinking and design. These will be gained throughout experience and feedback.
0. A use case of a class
There are many applications, on where to use an internal class to your C# code.
Data Transfer Object (DTO)
One application (of really many) and is used many times in software, is when you are transmitting data from database to your application for processing.
What better than writing an internal class that will store your data, implement useful and re-usable methods that can be used later in your application logic (e.g isAdministrator) and so on.
1. Object-Oriented Design Patterns
I will recommend you reading a book about Object-Oriented Design Patterns.
Books like that, describe some problems scenarios that can be implemented with a class using a pattern. Once you have read about these patterns and possible scenarios on where can be used, you will be able to get the book, find the pattern and solve your problem.
A co-worker of mine, state something really useful. When you are facing a problem, you should ask yourself:
"Does this problem solved again using a design pattern?"
If the answer is yes, then you go back to your reference book to find your design pattern, that will solve your problem, without re-inventing the wheel.
This approach, will teach you how and when you should use a separate class; but will also help you to maintain a communication language between you and your co-workers, that is, if you are talking about your code to a co-worker, you will be able to state the design-pattern and you will be immediately understood (given that, your co-worker know about the specific design-pattern).
2. Don't be afraid creating more than one internal classes
Another note, don't afraid to create multiple internal classes. Implement as much as possible, don't try to implement one internal class and mix responsibilities. Your class should be for a specific purpose, and should not do more than one thing (i.e responsibilities, if you are writing a class that is about transmitting data from your database to your application logic, should not - ideally - doing something else, like adding data to your database).
Consider learn more about Polymorphism, Inheritance, Encapsulation and Abstraction.
These four fundamental principles of Object Oriented Programming can also help you to learn how to structure your code object-oriented.
3. General Notes
As a Junior-Developer and not only as a Junior but as a Developer in general, you should always willing to learn from the more experience guys, by asking for feedback. Is not a shame is the law of learning and improve your code.
Another powerful source of learning, is books, consider buy some for the area you are interested in. (e.g Object Oriented Programming, Design Patterns etc).
As others noted in comments, this is really too broad and slightly opinionated, but big picture, use a class when:
You maintain state over time, and apply functions to this state.
You have a set of functions that share a common goal or deal with a common usage, data type or otherwise "obvious shared idea". That's particularly relevant when these functions can be reused in other places.
But really, to get a deeper understanding, get a book :-)
BTW, in C#, you can't put any functionality outside of a class, so the question should really be "how to divide my monolith class to smaller classes"
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