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.
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 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
My MVC's controller actions are getting huge. I want to create a service layer so that I can move code there. The idea is to use the SOLID principle: the controllers use the service layer to get the domain models that will be then transformed into view models.
My question is simple: Should my service layer be a new assembly (project) that will go along with my MVC project or should it be simply a class inside my already existing assembly (MVC Project)?
My approach will be similar to the following one, but unfortunately the post doesn't explain exactly how was the service layer defined:
http://weblogs.asp.net/gunnarpeipman/archive/2011/06/20/asp-net-mvc-moving-code-from-controller-action-to-service-layer.aspx
I would consider making the service layer a separate thing.
Service can be an interface-based object that is implemented either in-memory in the application or distributed and accessed remotely via SOAP, REST, RCP-XML, or anything else. The controller/client need not know or care if they have a client program that's interface based as well.
A dependency injection, interface based solution would allow you to inject client and service implementations in pairs so controllers need not be disturbed if you change how to access the services.
Controller is usually closely tied to a view. Views come and go, but services tend to remain. Services should map to business functionality that could be shared across applications.
Should my service layer be a new assembly (project)
Yes, it should. Other UIs might want to use it in the future...
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.
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
due to unit-testing we create for every class an Interface. The .Net Framework coding standards say that every class, interface, enum, etc. should be located in a different file.
As these interfaces are so closely related with the class we were thinking of creating an internal coding-standards rule to put together the class and the interface.
Have you seen this approach before? What do you think about it?
PD: Always talking about interfaces used only to mock the classes, not 'real' interfaces that can have more than one implementation.
You should follow .NET coding standards and separate the interfaces into their own files. You could create a folder Interfaces within your project. I usually have Concrete, Abstract and Interfaces folders within my projects.
Developers who may be unfamiliar with your solution will have a hard time finding interfaces if they are in class files.