Develop Reference

Where to put Data Logic in MVC? [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 2 years ago.
Improve this question
When setting up a MVC project I like to have seperate projects in my Visual Studio Solution. One project handles the main things, like Controllers and Views, and then I have a separate project for the Data Layer and one project for Utilities. The Main project references both the other projects. The Data Layer references the Utilities project.
With this structure I am facing a problem, when I try to implement a utility method like this:
public static string GetCountryFromID(int id)
{
dev_Entities dbContext = new dev_Entities();
var country = from c in dbContext.countries
where c.id == id
select c;
return country.FirstOrDefault().country_name.Trim();
}
The method works with the Database, but my Utilities project can't reference the Data Layer project, because otherwise there would be a circular dependancy, which is forbidden by Visual Studio. So what is the best way to work on the Database and where should I put the belonging utility methods?
Edit:
I chose this example for a utility method, because it's an action I have to do often and I would like to avoid duplicate code.

Regarding structure of the project, It is important to have separation by means of different project, for example Business logic, data access, utilities and so on.
This helps in achieving separation of concerns. But this is just one first step towards separation of concerns. To further strengthen it, use of interfaces is encouraged so that one implementation can be swapped easily with other type of implementation.
Regarding the issue of circular dependency, the method put up in Utility is not exactly a utility method, it is more of a data access method. I feel access to DBcontext should be done in a controlled manner from data layer project only.

What I usually do is on how I "architecture" my projects:
API/MVC with reference only to my DAL Services and DTOs
Then in my DAL, I split it up into two, Commands and Queries, with each action/query/update/create on each own class file. Also I either I add their my DTOs or on a different project. And they only references my Utilities/Services (String transformation, enum to string, etc.)
In your case, I would not call your GetCountryById as Utility or Service as it access database and only returns string. I would put it in my DAL>Queries as it access the database and only return a specifc part of it.

First Question: Is this a recommended structure?
Yes.
Second Question: With this structure I am facing a problem...
From your limited code example, I can't see where the conflict is. But, your Data Access project should have one job, and one job only: Talk to the database.
Your Data Access project SHOULD NOT NEED to know anything about your Utilities project. There should be nothing in the Utilities project that is needed by the Data Access project to talk to the database.
Also, you should not call the Data Access project from within the Utilities project either. The two should really not even know that the other exists.
A common structure should look like this, in a simple web-based app:
[UI]
|
[Business Logic]
| |
[Utility] [DataAccess]
Where each | represents a reference.
The method in your example, GetCountryFromID should be in the DataAccess project.
EDIT:
I should also add: It looks like you are using Entity Framework (EF). Your Data Access project should be the only project that has the EF .dll's in it. None of the other projects should know anything about EF. Among other advantages, if you ever want to swap out your data access tools (say to something like Dapper) then this change would only impact a single project.

C# - externalise classes in separated Class Libraries [closed]

Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 5 years ago.
Improve this question
Well, first excuse me if this is not the place to do so. This is not really a question, but I got exposed to that problem, and was pretty hard to find necessary information, so I thought would be good to make a subject just for it.
This is in attention to people with a "beginner/average" level in C# like me, so please if you have some comments or corrections to make please you are welcome.
It is around a year I was developping my project, using a lot classes. But I began to meet problems when I wanted to externalise some functions.
Why externalise my functions? In order to make support easier. In fact, creating an external LibraryClass (.dll), if in future I may make some modifies on it, and send an upgrade to customer, I only need to modify, and send that library, and not all the code.
The problem is when I want to use my classes from these libraries : It is just not possible.
Then a stackoverflower (thanks Simone Sifani) gave me the good idea : I may externalize all my classes in different projects(one project for each class).
In my case the thing became a bit difficult because all classes use each other... so I will explain how I proceeded.
1) make obviously a copy of your solution before beginning, so if you do something wrong, delete all then restart(and very good exercise to understand good how these references work, after one or two tries, you will all understand).
2) Add a Project in solution for each class you want to externalize (Right click on solution/Add new project/Class Library), then check directly the version of Framework to have the same version in all solution(in my case .NET Framework 4.6.2). If you don't, you will have no error message but debugging will not work without necessary an explaination.
3) Copy/Paste all the code of the original class in the new corresponding ClassLibrary. Then add the "public" word before each class definition.
class Myoldclass
{
...
}
becomes
public class Myoldclass
{
...
}
4) Add references (this is the longest part).
Each class may require different references :
- To .NET Frameworks
- To other classes(From now I will not use the word "class" but "Library")
I personally did the following :
4-1) put in commentary all the code that requires to use external libraries, so now you will have only errors regarding references missing on .NET Assemblies and some "unexisting functions(the ones I just put in commentary).
I also advise you to take a piece of paper, in order to write for each library, the list of references needed.
4-2) Add all references to necessary .NET Assemblies (for me was the longest part of the job). After that, you may have only errors regarding non existing functions.
4-3) Begin to compile all of your libraries that don't need to use any external library. It will then generate a .dll file in its directory (bin\debug directory). I will call it Library1
4-4) In all libraries that need to use Library1, add a reference to the libraries(Project/Add/Reference/Projects->Library1.dll file). So now all the code requiring Library1 may work correctly.(I will call that one Library2)
4-5) Once you think Library2 has references to all necessaries libraries, you can uncomment your code. For this I have two solutions : Just make Ctrl+Z until the code comes back to step 3. Inconvenient is sometimes VS found errors where there are not so you need to restart it, and so coming back is impossible.
In my case, I just opened my old classes, and overwrite all the code of my library, rewrite the "public" at class definition... and then start debugging to generate the Library2.dll file
4-6) Continue so on until all libraries get all references ok(that's why it is important to write on a paper, so by elimination, you will first debug the libraries having few references needed, and finish with the most difficult ones).
4-7) On your main project, add references to all previously generated dlls.
That's all, after it for my part my project is working as before(still have some problems to read Application parameters but I am on it). I have 13 Class Library projects in my solution, that I can debug separately, and everybody can use anybody :)
Hope that post will be useful to somebody, and if stackoverflowers want to help/correct I will try to keep it updated.

What is the point of creating as much projects? In most cases I do need a "Common" library and sometimes a library for DTO. Anyhow the main reason to move out those classes into a separate project is to minimize dependencies and to avoid polluting some of your layers...
In general I use these layers/projects:
- domain classes and domain logic with domain services - here I define also interfaces, which get's implemented inside service layer
- DAL (which is actually an ORM) - so here due mapping (or due domain classes being entities) we got a dependency on the domain classes (project)
- service layer - depending on both of the 2 projects above
- presentation (application) layer - where all your projects are referenced...
Mostly I do have a solution with 6-15 projects: 4 of them are based on the layers described above, but I do got additional ones, like domain events, domain event dispatcher (for the given DI used in the project), special libraries like HTML/PDF generation or email sending (with custom logic/templates), HttpClient libraries (spacial library to create and set up chain of handlers to do: auto-login, auto retry on HTTP 401, auto-retry on some errors or logging)...
So in short: as you see, most projects I add do have a function to fulfill. They're not class based. And there's a "polluted" project with a lot of extension and utility classes, where I do try to keep things tidy by trying to keep the classes in folders, giving them meaningful names...
In your case, if those class libraries are really re-usable, i'd possibly create them as a separate project and NuGet's. But if reuse is the goal, you need to strictly hold on some SOLID rules, otherwise a change in those classes for some feature in project A can easily break your business logic in project B.

Visual Studio C# - Tier Separation [closed]

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 6 years ago.
Improve this question
I'm learning about the different tiers in software development, such as the presentation tier, logic tier..etc.
So I have this RaceTrackSimulator project which is a Windows Forms Application. I want to separate all the classes (logic) from the GUI (presentation) and I did so like this:
But now the problem is, I don't know how to allow the classes to access and modify components of the GUI such as textboxes and labels. I think this is just a simple namespace issue, but that doesn't make sense because in each class it says:
namespace RaceTrackSimulator.BusinessLogic
How do I resolve such an issue?
Thanks!

You have just separated the business tier classes in separate folder which doesn't actually qualify as separate tier altogether. You should rather move all this classes in a separate project (example, class library project) and use the dll of that class library to your presentation tier form application.
You can as well choose, to write your business tier as WCF service and deploy them. In turn, your client/presentation layer will consume the service then to access business layer; which is one way good cause then for all different client's (UI or other) you don't have to ship the dll exclusively.
In your specific case, the problem could be that the namesspaces are different and in which case make sure, you are importing the correct namespace.

A few things it could be without looking at the actual code. The namespaces would be different from the 3 classes compared to your Form as they are in a different folder.
Also ensure that the components visibilty level is set to "Public" in the properties tab on the Form Designer. Once they are public, you should be able to access them in any of the 3 classes that you have created.

Did you put a
using RaceTrackSimulator.BusinessLogic;
At the top of the file where you are referencing your objects?

Where your code resides in terms of namespacing is irrelevant. You've done that fine. All you need to do is supply a means of accessing the components from your business logic classes. There's a multitude of ways of doing that depending on your requirements. You could supply a post(Object state) method in your form, and instantiate your logic class passing a reference to the form object. Your business logic can then simply post anything it likes back to the form and it's up to the form how it then handles the UI logic based on the data/message it receives from the logic layer. Or you could make your components more publicly visible to the logic layer. Or you provide an interface that allows access to the components directly.
Also, what you are calling Business Logic in your example above is not really logic. It's business model classes, by the looks of it.

How to break apart layers in a strict-layered architecture and promote modularity without causing unnecessary redundancy? [closed]

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 4 years ago.
Improve this question
I've received the go-ahead to start building the foundation for a new architecture for our code base at my company. The impetus for this initiative is the fact that:
Our code base is over ten years old and is finally breaking at the seams as we try to scale.
The top "layers", if you want to call them such, are a mess of classic ASP and .NET.
Our database is filled with a bunch of unholy stored procs which contain thousands of lines of business logic and validation.
Prior developers created "clever" solutions that are non-extensible, non-reusable, and exhibit very obvious anti-patterns; these need to be deprecated in short order.
I've been referencing the MS Patterns and Practices Architecture Guide quite heavily as I work toward an initial design, but I still have some lingering questions before I commit to anything. Before I get into the questions, here is what I have so far for the architecture:
(High-level)
(Business and Data layers in depth)
The diagrams basically show how I intend to break apart each layer into multiple assemblies. So in this candidate architecture, we'd have eleven assemblies, not including the top-most layers.
Here's the breakdown, with a description of each assembly:
Company.Project.Common.OperationalManagement : Contains components which implement exception handling policies, logging, performance counters, configuration, and tracing.
Company.Project.Common.Security : Contains components which perform authentication, authorization, and validation.
Company.Project.Common.Communication : Contains components which may be used to communicate with other services and applications (basically a bunch of reusable WCF clients).
Company.Project.Business.Interfaces : Contains the interfaces and abstract classes which are used to interact with the business layer from high-level layers.
Company.Project.Business.Workflows : Contains components and logic related to the creation and maintenance of business workflows.
Company.Project.Business.Components : Contains components which encapsulate business rules and validation.
Company.Project.Business.Entities : Contains data objects that are representative of business entities at a high-level. Some of these may be unique, some may be composites formed from more granular data entities from the data layer.
Company.Project.Data.Interfaces : Contains the interfaces and abstract classes which are used to interact with the data access layer in a repository style.
Company.Project.Data.ServiceGateways : Contains service clients and components which are used to call out to and fetch data from external systems.
Company.Project.Data.Components : Contains components which are used to communicate with a database.
Company.Project.Data.Entities : Contains much more granular entities which represent business data at a low level, suitable for persisting to a database or other data source in a transactional manner.
My intent is that this should be a strict-layered design (a layer may only communicate with the layer directly below it) and the modular break-down of the layers should promote high cohesion and loose coupling. But I still have some concerns. Here are my questions, which I feel are objective enough that they are suitable here on SO...
Are my naming conventions for each module and its respective assembly following standard conventions, or is there a different way I should be going about this?
Is it beneficial to break apart the business and data layers into multiple assemblies?
Is it beneficial to have the interfaces and abstract classes for each layer in their own assemblies?
MOST IMPORTANTLY - Is it beneficial to have an "Entities" assembly for both the business and data layers? My concern here is that if you include the classes that will be generated by LINQ to SQL inside the data access components, then a given entity will be represented in three different places in the code base. Obviously tools like AutoMapper may be able to help, but I'm still not 100%. The reason that I have them broken apart like this is to A - Enforce a strict-layered architecture and B - Promote a looser coupling between layers and minimize breakage when changes to the business domain behind each entity occur. However, I'd like to get some guidance from people who are much more seasoned in architecture than I am.
If you could answer my questions or point me in the right direction I'd be most grateful. Thanks.
EDIT:
Wanted to include some additional details that seem to be more pertinent after reading Baboon's answer. The database tables are also an unholy mess and are quasi-relational, at best. However, I'm not allowed to fully rearchitect the database and do a data clean-up: the furthest down to the core I can go is to create new stored procs and start deprecating the old ones. That's why I'm leaning toward having entities defined explicitly in the data layer--to try to use the classes generated by LINQ to SQL (or any other ORM) as data entities just doesn't seem feasible.

I would disagree with this standard layered architecture in favor of a onion architecture.
According to that, I can give a try at your questions:
1. Are my naming conventions for each module and its respective assembly following standard conventions, or is there a different way I
should be going about this?
Yes, I would agree that it is not a bad convention, and pretty much standard.
2. Is it beneficial to break apart the business and data layers into multiple assemblies?
Yes, but I rather have one assembly called Domain (usually Core.Domain) and other one called Data (Core.Data). Domain assembly contains all the entities (as per domain-driven-design) along with repository interfaces, services, factories etc... Data assembly references the Domain and implements concrete repositories, with an ORM.
3. Is it beneficial to have the interfaces and abstract classes for each layer in their own assemblies?
Depending on various reasons. In the answer to the previous question, I've mentioned separating interfaces for repositories into the Domain, and concrete repositories in Data assembly. This gives you clean Domain without any "pollution" from any specific data or any other technology. Generally, I base my code by thinking on a TDD-oriented level, extracting all dependencies from classes making them more usable, following the SRP principle, and thinking what can go wrong when other people on the team use the architecture :) For example, one big advantage of separating into assemblies is that you control your references and clearly state "no data-access code in domain!".
4. Is it beneficial to have an "Entities" assembly for both the business and data layers?
I would disagree, and say no. You should have your core entities, and map them to the database through an ORM. If you have complex presentation logic, you can have something like ViewModel objects, which are basically entities dumbed down just with data suited for representation in the UI. If you have something like a network in-between, you can have special DTO objects as well, to minimize network calls. But, I think having data and separate business entities just complicates the matter.
One thing as well to add here, if you are starting a new architecture, and you are talking about an application that already exists for 10 years, you should consider better ORM tools from LINQ-to-SQL, either Entity Framework or NHibernate (I opt for NHibernate in my opinion).
I would also add that answering to as many question as there are in one application architecture is hard, so try posting your questions separately and more specifically. For each of the parts of architecture (UI, service layers, domain, security and other cross-concerns) you could have multiple-page discussions. Also, remember not to over-architecture your solutions, and with that complicating things even more then needed!

I actually just started the same thing, so hopefully this will help or at least generate more comments and even help for myself :)
1. Are my naming conventions for each module and its respective assembly following standard conventions, or is there a different way I should be going about this?
According to MSDN Names of Namespaces, this seems to be ok. They lay it out as:
<Company>.(<Product>|<Technology>)[.<Feature>][.<Subnamespace>]
For example, Microsoft.WindowsMobile.DirectX.
2.Is it beneficial to break apart the business and data layers into multiple assemblies?
I definitely think its beneficial to break apart the business and data layers into multiple assemblies. However, in my solution, I've create just two assemblies (DataLayer and BusinessLayer). The other details like Interfaces, Workflows, etc I would create directories for under each assembly. I dont think you need to split them up at that level.
3.Is it beneficial to have the interfaces and abstract classes for each layer in their own assemblies?
Kind of goes along with the above comments.
4.Is it beneficial to have an "Entities" assembly for both the business and data layers?
Yes. I would say that your data entities might not map directly to what your business model will be. When storing the data to a database or other medium, you might need to change things around to have it play nice. The entities that you expose to your service layer should be useable for the UI. The entities you use for you Data Access Layer should be useable for you storage medium. AutoMapper is definitely your friend and can help with mapping as you mentioned. So this is how it shapes up:
(source: microsoft.com)

1) The naming is absolutely fine, just as SwDevMan81 stated.
2) Absolutely, If WCF gets outdated in a few years, you'll only have to change your DAL.
3) The rule of thumb is to ask yourself this simple question: "Can I think of a case where I will make smart use of this?".
When talking about your WCF contracts, yes, definitely put those in a separate assembly: it is key to a good WCF design (I'll go into more details).
When talking about an interface defined in AssemblyA, and is implemented in AssemblyB, then the properties/methods described in those interfaces are used in AssemblyC, you are fine as long as every class defined in AssemblyB is used in C through an interface. Otherwise, you'll have to reference both A, and B: you lose.
4) The only reason I can think of to actually move around 3 times the same looking object, is bad design: the database relations were poorly crafted, and thus you have to tweak the objects that come out to have something you can work with.
If you redo the architecture, you can have another assembly, used in pretty much every project, called "Entities" that holds the data objects. By every project i meant WCF as well.
On a side note, I would add that the WCF service should be split into 3 assemblies: the ServiceContracts, the Service itself, and the Entities we talked about. I had a good video on that last point, but it's at work, i'll link it tomorow!
HTH,
bab.
EDIT: here is the video.

Resolving Circular References (C#)

I'm having a couple of problems with circular reference/dependency that I've been sitting on all day. Something must be wrong with my thought process, I just don't get it.
Here are my projects:
Flip.Main (ASP.NET MVC)
Flip.Domain (C# DLL)
Flip.Services (C# DLL)
Flip.Utility (C# DLL)
Current References/Dependencies:
Flip.Main -> Flip.Domain, Flip.Services, Flip.Utility
Flip.Services -> Flip.Domain, Flip.Utility
Flip.Domain -> Flip.Utility
I wanted to structure my project in a way that my services project has all services, my domain project the model, repository and 'fluent' extensions to query the model, and the main and utility project are pretty much self explanatory.
Problems encountered:
1) I have an EmailService in my Flip.Services project, which needs to send out localized emails. All localization is done in Flip.Main's App_GlobalResources. No idea how to get the strongly typed emails and other localized resources now to my service layer as Flip.Main already depends on the service layer and therefore I can have it depend back to the Main project.
2) I have business classes, e.g. CustomerSearchFilter which represents a strongly typed search query. I want those business classes outside of the Flip.Domain project because they are not part of the domain model. However, in my CustomerSearchFilter class I have domain class instances (e.g. CustomerGroup) so it needs to know about domain classes. At the same time my Fluent interface in my Flip.Domain project needs to know what CustomerSearchFilter is so I can apply it to my IQueryable interface. Circular reference again.
3) I have a custom [AuthorizeSessionState] attribute which I use to decorate specific controller actions in my ASP.NET MVC Flip.Main project. This is an ActionFilterAttribute which needs to instantiate my SessionService who resides in my Flip.Services project. I can't put this into my Utility class though (because Flip.Services already references Flip.Utility). I don't think they should be in Flip.Main either - do I have to make another project for this!?
(20 more)
I feel like I'm making a mistake somewhere down the line, especially when I read that others usually don't encounter circular reference problems. Help?

Use interfaces for all non-trivial classes. Place interfaces in a different assembly from implementation.

The question comes down to what you separate by namespace and what you separate by DLL. If you have a good reason to keep EVERYTHING modular, you have to work really hard. But if each of these dlls only have a class or two in them, perhaps you could merge them together?

Take a few minutes and sort out the procedures ... create an identifier for each project (FM, FS, FD, FU). List each publicly accessible procedure on a page and then add an identifier for a project, if that project uses the procedure ...
Then you can see which procedure needs to be in (or accessible to) which project.
Hope that helps!

You can put your localized email strings in Flip.Services. The downside is that you have two places to maintain localized resources. You can also have a separate dll for all your resources to minimize the place to edit resources.
You have to move the fluent interface to an other dll or make CustomerSearchFilter part of the domain.
You will need to add more projects or rearrange your structure and use namespaces to create the separation.

It sounds like your building on concrete implementations instead of interfaces/contracts. As Ima suggests define interfaces that describe what a certain class should be able to do. Use this interface when you declare properties, parameters and the like. Keep the interfaces separate from the implementaion and both the implementation and the projects that uses the interface can reference the interface project.
You then get the nice option of using dependency injection making your code easier to test as an a side

In the "tiers" of a domain, repositories and services live at the same logical level, above the domain in an infrastructure role. I would suggest moving your repository implementations (queries, etc.) outside of the domain itself. That solves #2 at least.