Non-object-oriented + What is a custom object?

Non-object-oriented

You cannot use DataSet only because DataSet is an object, while C # and Visual Basic. NET are object-oriented (OO) languages. The "hello world" of OO programming is a typical Person class, which is a subclass of Employee. However, DataSet does not make such inheritance or most other OO technologies possible (or at least make them natural/intuitive ). Scott Hanselman is a strong supporter of class entities and he has made the best explanation:

"DataSet is an object, right? But it is not a domain object, it is not an 'apple' or 'orange', but an object of the 'dataset' type. DataSet is a bowl (it knows it supports data storage ). DataSet is an object that knows how to save rows and columns. It knows databases very well. However, I do not want to return a bowl. I want to return a domain object, for example, 'apple '." 1

DataSet maintains a relationship between data to make them more powerful and easy to use in relational databases. Unfortunately, this means that you will lose all the benefits of OO.

Because DataSet cannot be used as a domain object, you cannot add functions to them. Normally, objects have fields, attributes, and methods, and their behavior is targeted at class instances. For example, you may associate the Promote or CalcuateOvertimePay function with the User object. This object can be safely called through someUser. Promote () or someUser. CalculateOverTimePay. Because the method cannot be added to DataSet, you need to use the utility function to process weak objects and include more instances of hard-coded values in the entire code. Generally, you end with the Process Code. In the process code, you must constantly retrieve data from DataSet, either they are stored in local variables in a cumbersome way and passed to other locations. Both methods have disadvantages and do not have any advantages.

Opposite to DataSet

If you think that the data access layer should return DataSet, you may miss some important advantages. One of the reasons is that you may be using a thin or nonexistent business layer. In addition to other problems, it also limits your ability to abstract. In addition, it is difficult to use the OO technology because you are using a general pre-compiled solution. Finally, tools such as Visual Studio. NET make it impossible for developers to easily use weak objects (such as DataSet), reducing efficiency and increasing the possibility of errors.

All these factors have a direct impact on the maintainability of the Code in different ways. Lack of abstraction makes functional improvements and bug fixes more complex and dangerous. You cannot take full advantage of the code reuse or readability improvements provided by OO. Of course, whether your developers process business logic or presentation logic, they must understand your basic data structure very well.

Back to Top
Custom object class
Most issues related to DataSet can be solved by using the rich features of OO programming in a clearly defined business layer. In fact, we want to obtain data (databases) organized by relationship and use the data as an object (CODE. This concept is not to obtain the DataTable that saves the vehicle information, but to obtain the vehicle object (called a custom object or domain object ).

Before learning about custom entities, let's take a look at the challenges we will face. The most obvious challenge is the amount of code required. Instead of simply getting data and automatically filling in DataSet, we get the data and manually map the data to a custom object (which must be created first ). Since this is a repetitive task, we can use the code generation tool or the O/R Er (which is described in detail later) to reduce the workload. The bigger problem is the specific process of ing data from the relational world to the object world. For simple systems, ing is usually direct, but with the increase in complexity, the difference between the two worlds will cause problems. For example, inheritance is an important technology in the object world to obtain code reuse and maintainability. Unfortunately, inheritance is a strange concept for relational databases. Another example is that the relational processing method is different: the object world relies on maintaining the reference of a single object, while the relational world uses foreign keys.

Because the number of codes and the differences between relational data and objects keep increasing, it seems that this method is not very suitable for more complex systems, but the opposite is true. By isolating various problems into one layer, that is, the ing process (which can also be automated), complex systems can also benefit from this method. In addition, this method is often used, which means that the increasing complexity can be completely solved through several existing design patterns. The shortcomings of the DataSet discussed earlier will multiply in the complex system. Finally, you will come up with a system that lacks flexibility and adaptability, which is more difficult to build.

Let's take a look at this section. I may understand why I try not to use DataSet.

What is a custom object?

Custom entities are the objects representing the business domain. Therefore, they are the foundation of the business layer. If you have a User Authentication Component (this example is used throughout this Guide), you may have User and Role objects. E-commerce systems may have Supplier and Merchandise objects, while real estate companies may have House, Room, and Address objects. In your code, user-defined entities are just some classes (entities and "classes" are closely related, as they are used in OO programming ).