0

Recommendations I understood in Java (which has a lot of restrictions, @ least for me), even with hibernate was to have separated layers

  • Entities like persons, children, users, etc...
  • DAO entities linked to database
  • Service providing entities and functionalities, where I'll do the SQL
  • WebService providing an interface over needs

As I'm starting with Eiffel and store, I'm facing some difficulties I face since ever in programming (hoping there's somebody in this earth who has not the same problem) I always want to generalize things more than necessary. Every time I do a copy-paste, I refactor and look for a solution which makes me able to write it one time... which takes time and time on the delivery of the software, but for me adds more quality and flexibility to the software. I'm actually working alone in a company where I'm going to be the lead developer and if the future wants we'll be more developers. The goal is to develop a platform of services in Eiffel, postgresql-odbc, and an Angular-web front-end.

I'd like to have the more generic pattern to be able to manage entities in the future with typical situations as:

  • Database entities
  • Relationships
    • one_to_one
    • one_to_many
    • many_to_one
    • many_to_many

@ The point I'm now, I'm about to develop an architecture which ideally for me has:

  • DB_ENTITY which as relations: BAG[RELATIONSHIP[P,S]] where P=Primary and S=Secondary
  • Primary is P->DB_ENTITY when ONE and BAG[P] when MANY
  • A COMPANY on my design will inherit from DB_ENTITY and add relationships as a BRANCH. So I was thinking having in my COMPANY class branches: RELATIONSHIP[like Current, BRANCH]

The relationship classes would help me to create the CRUD SQL statements into the "service" layer in a more abstract manner.

enter image description here

  • when I try something more lightweight I find restrictions in the pattern where I have to repeat operations... thats a bit my difficulty
  • Do you think of any disadvantages of such model I'm creating out of the first shot of development?
Pipo
  • 4,653
  • 38
  • 47
  • You are re-designing part of the state of a DBMS--while not understanding the RM (relational model). The best (though flawed) RM design method is Object-Role Modeling (FCO/IM & NIAM descendant). RM/ER tables represent relation(ship)s/associations. Cardinalities are (derived coincidental constant) properties of relationships & a ORM/pseudo-ER "relationship" is not a relationship but a FK (foreign key)--a particular kind of constraint, hence a (constant) property of a database. PS Continue & soon you'll be another discoverer of anti-pattern [EAV](https://stackoverflow.com/a/32285603/3404097) ... – philipxy Oct 25 '18 at 12:35
  • ... ORMs supply little value--they are for managing a trivial RM design of *a (OO/3GL) implementation of a system*, but the point of a RM design is to model & generically manipulate *the system*. "Database entities" are abstractions that database tables assert about. ORMs, pseudo-ER pre-RM models & even the ERM misunderstand the RM. So learn the RM & use it. Where relationally characterized state & its generic queries are too large or slow then implement special cases of state & methods in OO/3GLs. Then you might want an ORM to manage OO state in a way also easily accessible relationally. – philipxy Oct 25 '18 at 12:37
  • @philipxy thx for all your comments but I'm having a hard time understanding you, could you provide me some links or more trivial readable comments? – Pipo Oct 25 '18 at 12:55
  • If I get a chance I'll revisit, thought I'd give you some things to look up. Don't know about answering--your question now is pretty vague. What use are you making of objects typed per your diagram? It's not clear what "such" means in "such a model", or what use to evaluate it for, or against what alternatives. It's hard to imagine your question getting specific engough to suit [ask]. – philipxy Oct 25 '18 at 13:15
  • @philipxy I'll try to be more specific and will revisit my question, for that I'd have to go further in my model/implementation. But my idea is really to get a classical ER model into the DB its in my software that I'm trying to get an abstraction layer on hard coding every SQL statement for CRUD and relationships if I missed the specificity of this point in my question – Pipo Oct 25 '18 at 13:28

1 Answers1

0

Quenio dos Santos not wanting to create an account on stackexchange, I'll quote its answer which could be useful for others

I recommend the book: https://www.amazon.com/Domain-Driven-Design-Tackling-Complexity-Software-ebook/dp/B00794TAUG/ref=sr_1_2?s=digital-text&ie=UTF8&qid=1540350158&sr=1-2&keywords=domain+driven+design&dpID=51OWGtzQLLL&preST=_SY445_QL70_&dpSrc=srch

Not just because of the Repository pattern.

You should be able to implement reusable, abstract classes out of the repository pattern if you want to get away from repetitive code. In Java, MyBatis is a framework that helps with that. I really don’t know if there is anything equivalent in Eiffel. I’m also a new Eiffel developer.

Some pros-and-cons of the Repository pattern:

  • You define the SQL yourself. Some see it as a cons, but some see it as a pros, because you have clear understanding of the mapping from the database to your classes, and it allows you to optimize your queries, and join several tables into a single class, or smaller number of classes, when approriate in your context.
  • More freedom on how you define your domain model. It can be quite different from the schema of your database. Your classes don’t have to be just a set of anemic attribute holders of the tables in your database, but they can have behavior and be useful and expressive in a setting completely independent from your database.
  • ORM frameworks, like Hibernate, are sometimes hard-to-use for a new developer not very familiar with them. With the repository pattern, because the mapping is so clear and available in your own code, it tends to be easier to understand and debug.
  • You can also have different implementations of your repositories for different technologies, such as NoSQL databases. With ORM frameworks, you tend to be stuck with a relational database, unless you rework quite a bit of your dependencies on the ORM framework. It is easier to encapsulate the data store technology behind repositories, and keep a clean separation between your domain model and your database.

I’d say those are the main points. Having said that, these are very general guidelines. I don’t have any experience with data persistent in Eiffel, so I couldn’t say what are the best practices for Eiffel developers. But I have a gut feeling that the repository pattern fits well Eiffel because the original goal of the language was to build more abstract, domain-rich class libraries, which is the purpose behind the repository pattern. (By the way, I’m calling it a pattern, but I’m not sure the author calls it that. The author would probably call aggregates, entities and repositories, all kinds of classes used in domain-driven design, all together a pattern.)

Pipo
  • 4,653
  • 38
  • 47