Where to place business objects, listings, custom exceptions?

Question

I am trying to figure out how to split my objects between data, business and user interface layers. Is it better to create a separate project for these objects to which all levels will refer? What about Enums and custom exceptions? I have some listings used only by the UI project, and some of them are used in business. Does this mean that I have to have two separate Enum folders: one in the business project and one in the user interface? Similar to Exceptions? So far, I have supported objects, enumerations, and exceptions in one separate project referenced by all three levels.

My business project has manager classes (e.g. ProductManager.cs) that have methods such as List GetProducts () and SaveProduct (Product), etc.

Answer 1

If these entities have semantic meaning in all these levels, I would recommend placing them in a separate project / assembly, which all levels are aware of.

If you have objects belonging to one layer, I would limit them to this layer. For example, you do not allow the user interface code to throw a Business Layer or Business Layer exception to use the user interface enumeration.

Depending on what you are doing, there can be no harm in keeping layer-specific types in the same project / assembly that you are maintaining your generic types, but I would consider limiting them to my own level of better practice.

Answer 2

You are doing the right thing. Creating a separate project with all entities is almost always the way to go. If enumerations and exceptions are associated with an entity, they are also there.

Answer 3

Think about encapsulation. Place them in an area where they are needed, and not in a wider range.

If something is used only within the user interface layer, do not expose it to other layers. But if it is used at two or three levels, then define it at the lower level (for example, if the user interface is in Business Logic, which is based on the database, then something that is used in BL and UI can simply be determined in BL). Or, if something is more or less global, move it to a third-party shared library.

Also, first try to minimize the need to use shared objects: for example, It is recommended (for good reason) to avoid custom exceptions. Most of them can usually be represented by an existing system exception with a bit of additional information (for example, InvalidOperationException with details in the message), which minimizes the need to handle the whole new class of exceptions everywhere - and courses that eliminate the need to decide where to define a custom exception type.

Answer 4

I usually put enums and user exceptions along with interface definitions in a separate project.

Answer 5

If you need entities at all levels, then using a separate project (imo) is best.