Question How to structure a project?

mohamedG

New member
Joined
May 29, 2019
Messages
3
Programming Experience
3-5
Hello,

I applied recently for a job and one of the comments I got was that my project structure is very weird.
I tried to structure the project into layers and folders.
Core => For my data models.
Infrastructure => For reading external files from the local hard disk.
Repository => To execute the database commands.
Service =>For my business logic and to interact with the user interface
Helper Class => Static class.

I don't know what is wrong with that structure so perhaps someone can guide me.

Thanks in advance

534
 

Skydiver

Well-known member
Joined
Apr 6, 2019
Messages
919
Location
Virginia Beach, VA
Programming Experience
10+
Most shops follow the MVVM or MVC layouts for their projects. Some shops will follow a Java style layout of files.
 

mohamedG

New member
Joined
May 29, 2019
Messages
3
Programming Experience
3-5
So, nothing wrong with my structure I guess, it is just their point of view then.
 

Skydiver

Well-known member
Joined
Apr 6, 2019
Messages
919
Location
Virginia Beach, VA
Programming Experience
10+
My only quibbles with your structure:
Services is a misnomer if it actually contains business logic and UI interaction. If I would have rather have business logic in a folder named BusinessLogic for the business logic; and/or a folder named View for the UI interaction.
Core being at the top level containing various files that look to be domain class files. I'd rather see those files in a Model subdirectory.
I would rename the top level Core to be the major name of the component or namespace. Very likely, I would keep the main entry point, helper class file, and the Autofac bootstrapper there at that top level. Just my personal preference: I would get rid of the Interfaces directory and move the interface files up to the top level.

To me, it seems that your Infrastructure directory contains a set of facades for the OS or other external components. If you use Autofac, I'm guessing that you also use Moq or some other mocking library and this is why these files are here -- the code in the infrastructure does the actual talking to external components, while the rest of your code simply talks to interfaces which will be hooked up to infrastructure when running live, but hooked up to mocks when unit testing. I do something similar and have those files in an DataAcess assembly.

Having my DataAccess assembly does an interesting thing to my layout, though. My repositories also live with the core component assembly, but they all talk to an interface where the concrete implementation is in DataAccess. For unit tests they all talk to mocks.
 

Sheepings

Senior Programmer
Joined
Sep 5, 2018
Messages
844
Location
UK
Programming Experience
10+
I agree with Skydiver re model sub directories, and the core being named something reflective of the main namespace, but then again, I tend to think alike him in terms of logic, but not everyone does think alike, and to be honest with you. I think they don't have a problem with your structure as such, but more so, they are quibbling about some of your naming conventions of your file names and the structures these files reside under. While I believe that this type of question can not be answered accurately, because it reflects differently as par each own personal opinion and preference. However, I don't think I would be putting GetBuisnessRoles, GetClients, Get Users in a repository directory. But I am only going on the assumption of what I imagine those files consist of in terms of the context written within them. I don't think that your structure is totally inappropriate or bemusing, but it could probably do with some tweaks in everybody's opinion; but that doesn't mean that you should change your structure, a structure you are used to or comfortable with, just because someone else doesn't like it.

Have they asked you to do it an alternative way?
 

Sheepings

Senior Programmer
Joined
Sep 5, 2018
Messages
844
Location
UK
Programming Experience
10+
Then my advice is; don't change it.
 
Top Bottom