Tag Info

New answers tagged

1

I'm assuming that you're using .NET for development since you mentioned MSSQL as your database but my recommendations apply to O/RMs available for other platforms as well. CRUD Soft Deletes and Auditing For your first issue, CRUD operations and filtering of "soft deletes". The O/RM itself provides a foundation that allows for more complex scenarios to be ...


0

Call delete method, which sets the delete flag and updates the object. ORMs have some impressive functionality beyound simple CRUD operations. And they still allow SQL as a fall back. If by 'the application' you mean the UI, then the real reason for the middle layer is so you don't have a 'Smart UI' design which becomes harder and harder to maintain and ...


3

Have you considered hiring your developers and then letting them decide what architecture to use? By doing this you will ensure that you aren't excluding developers from the selection process simply because they don't like the architecture you've chosen. Getting the best possible team of developers is the most important thing for ensuring your project is ...


1

You want to build a database with all the accessibility code and business logic and then hire developers to build some sort of user interface. You're taking on a lot of the development responsibility here and not giving the developers enough room to do their job. Is there some reason you don't feel you're going to hire competent people who can help you ...


3

First of all no matter what you choose you want your business logic outside your database as much as possible. There are many reasons for this, the top couple being you get tied to your database so if you need to change to Oracle or SQL Server it becomes a much harder task, SQL isn't designed to handle business logic gracefully which results in massive ...


1

As I see it, the ORM doesn't create the side effects, your code does. If you ask an ORM to save an entity, it does so, without performing additional operations, or should there be a database trigger of some sort, in my personal opinion you should remove it in favor of having more control in your program. As such, don't worry about saving your entity ...


2

The rule I use quite often is to remove the plural and the subject from the original property name, then add "to". In your example, I would probably end up with: public class Box { public long BoxId { get; set; } public virtual Process InputTo { get; set; } /* ugly name */ public virtual Process OutputTo { get; set; } /* ugly name */ } ...


1

I don't know how it's modeled in your application, but in the real world, people cannot only be both student and worker, they can be workes at different companies at the same time. Now looking closer at the tables shows that they look like N:N join tables, don't they? So what I would do is rename Student to Enrollment and Worker to Contract. Person now has ...


3

One way to do this would be to model this in the application using composition: //maps to the table PEOPLE class Person { String name; Date birthdate; GenderEnum gender; Worker workerAttributes; Student studentAttributes; } //maps to the table WORKERS class Worker { String name; String company; Date since; } //maps to the table ...


0

It depends. Starting with persistent-only attributes is the most typical approach, and adding non-persistent attributes should typically be an exception. But such a decision is always a trade-off, and where you draw the line depends on the responsibilities you assign to that object. Some typical reasons for adding non-persistent attributes: you need them ...


0

It sounds like you are. If you have metadata for the model object that doesn't get persisted, I suppose you could wrap the model object in another object that contains the metadata to reduce confusion about what is and is not part of the model. One way to do it might look something like: //Model that will actually be persisted class UserProfile { String ...


0

It sounds like you're having exactly the same kind of problem that led to me adopting an object database rather than relational in one of my current projects. Using an object database, you could simply have Message holding a non-nullable reference to MessageClass object, with ClassA, ClassB and ClassC being subtypes of MessageClass. While this is basically ...


1

What you have called "Table Per Hierarchy" resembles what Martin Fowler and others have called "Class Table Inheritance". See Diagram. I would call this mimicking inheritance rather than implementing inheritance. One technique that can be used to good advantage in some cases of class table inheritance is called "shared primary key". See tag wiki in SE. ...


1

Going with that last option in your edit but altering it a little. In this, you abstracted away any changes in concrete class. In your database however, you are saving the value of an enum that saves which kind of concrete class you are referring to, and what that concrete class' id is. This info can be passed to the factory, which should provide a ...


1

It makes a difference of what ClassA and ClassB really represent - generic names are not helpful for making good design decisions. For example, if those are things which can or should be modeled with a common base class, with a real "is-a" relationship, go that route. If ClassA and ClassB have nothing in common except those message, then inheritance is ...


3

Add a field main_address_id in the User entity or table that holds the ID of the Address record that is the main one. Make that a one to one relationship, if you like. The only solution I have now is to create another One-to-One relationship between Users.main_address and Address but this does not insure that the main_address will actually be part of ...



Top 50 recent answers are included